Paragon Automation, ປ່ອຍ 24.1

ຈຸດເດັ່ນຂອງຊອບແວ

• ຮອງຮັບ RHEL 8.10
• ຄວາມສາມາດສໍາລັບຜູ້ໃຊ້ທີ່ບໍ່ແມ່ນຮາກເພື່ອດໍາເນີນການຄໍາສັ່ງໃນ paragon CLI utility
• ຄວາມສາມາດໃນການສະໜອງນະໂຍບາຍການກຳນົດເສັ້ນທາງຂອງພາກສ່ວນໃນອຸປະກອນ Cisco IOS XR ໂດຍໃຊ້ NETCONF

ແນະນຳ

Juniper® Paragon Automation ເປັນໂຊລູຊັ່ນທີ່ມີເມຄສໍາລັບການວາງແຜນເຄືອຂ່າຍ, ການຕັ້ງຄ່າ, ການສະຫນອງ, ວິສະວະກໍາການຈະລາຈອນ, ການຕິດຕາມ, ແລະການຄຸ້ມຄອງວົງຈອນຊີວິດທີ່ນໍາເອົາຄວາມສາມາດໃນການເບິ່ງເຫັນແລະການວິເຄາະແບບພິເສດໃນການຄຸ້ມຄອງແລະການຕິດຕາມເຄືອຂ່າຍ. ທ່ານ​ສາ​ມາດ​ນໍາ​ໃຊ້ Paragon Automation ເປັນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ໃນ​ສະ​ຖານ​ທີ່ (ການ​ຄຸ້ມ​ຄອງ​ລູກ​ຄ້າ​)​.
Paragon Automation ດໍາເນີນການກ່ຽວກັບສະຖາປັດຕະຍະກໍາທີ່ອີງໃສ່ microservices ແລະຈ້າງ REST APIs, gRPC APIs ແລະການສື່ສານລົດເມທົ່ວໄປ. 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.

ໝາຍເຫດ:
ທ່ານສາມາດຍົກລະດັບໂດຍກົງຈາກ Paragon Automation Release 23.2 ໄປເປັນ Release 24.1 ເທົ່ານັ້ນ. ຖ້າການປ່ອຍຂອງເຈົ້າແມ່ນໄວກວ່າ Release 23.2, ທ່ານຕ້ອງຕິດຕັ້ງ Release 24.1 ໃໝ່. ຢ່າງໃດກໍຕາມ, ເພື່ອຍ້າຍການຕັ້ງຄ່າການປ່ອຍປະຈຸບັນຂອງທ່ານໄປເປັນ Release 24.1, ທ່ານສາມາດນໍາໃຊ້ການສໍາຮອງຂໍ້ມູນແລະການຟື້ນຟູການທໍາງານ. ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບການອັບເກຣດ, ເບິ່ງ Upgrade to Paragon Automation Release 24.1.

ໃບອະນຸຍາດ

ໃນ Paragon Insights, ພວກເຮົາໄດ້ນໍາສະເຫນີຊັ້ນໃບອະນຸຍາດຕໍ່ໄປນີ້ແລະໃບອະນຸຍາດອຸປະກອນທີ່ກ່ຽວຂ້ອງຂອງພວກເຂົາ:

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

ປະຈຸ​ບັນ, ​ໃບ​ອະ​ນຸ​ຍາດ​ຊັ້ນ​ແມ່ນ​ຖືກ​ບັງ​ຄັບ​ໃຊ້. ນັ້ນແມ່ນ, ທ່ານບໍ່ສາມາດປະຕິບັດການປັບໃຊ້ໄດ້ເວັ້ນເສຍແຕ່ວ່າທ່ານເພີ່ມໃບອະນຸຍາດ.
ໃບອະນຸຍາດອຸປະກອນຖືກບັງຄັບໃຊ້ແບບອ່ອນໆ. ນັ້ນແມ່ນ, ທ່ານຈະໄດ້ຮັບການແຈ້ງເຕືອນທີ່ບໍ່ປະຕິບັດຕາມໃນ Paragon Automation GUI ຖ້າທ່ານພະຍາຍາມໃຊ້ອຸປະກອນຫຼາຍກວ່າຈໍານວນທີ່ທ່ານໄດ້ຮັບໃບອະນຸຍາດ.
ຢ່າງໃດກໍຕາມ, ທ່ານສາມາດສືບຕໍ່ນໍາໃຊ້ຫນ້າທີ່ທີ່ມີຢູ່ແລ້ວ.
ເຈົ້າສາມາດ view ສະຖານະການປະຕິບັດຕາມໃບອະນຸຍາດຂອງທ່ານໃນຫນ້າບໍລິຫານ> ການຈັດການໃບອະນຸຍາດໃນ GUI.
ໃນ Paragon Pathfinder, ພວກເຮົາໄດ້ບັງຄັບໃຊ້ລະດັບໃບອະນຸຍາດດັ່ງຕໍ່ໄປນີ້:

• ມາດຕະຖານ Pathfinder
• Pathfinder Advanced
• Pathfinder Premium

ສໍາລັບຂໍ້ມູນກ່ຽວກັບການອອກໃບອະນຸຍາດ, ເບິ່ງໄດ້ ຄູ່ມືການອອກໃບອະນຸຍາດ.
ຖ້າທ່ານມີລະຫັດໃບອະນຸຍາດທີ່ຖືກສ້າງຂຶ້ນສໍາລັບສະບັບຂອງ Paragon Automation ກ່ອນການປ່ອຍ
22.1 ທ່ານຈະຈໍາເປັນຕ້ອງໄດ້ຍົກລະດັບຮູບແບບລະຫັດໃບອະນຸຍາດເປັນຮູບແບບໃຫມ່ກ່ອນທີ່ທ່ານຈະສາມາດຕິດຕັ້ງມັນຢູ່ໃນ Paragon Automaton Release 24.1. ທ່ານສາມາດສ້າງລະຫັດໃບອະນຸຍາດໃຫມ່ໂດຍໃຊ້ Juniper Agile Licensing portal. ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບການສ້າງລະຫັດໃບອະນຸຍາດໃຫມ່, ເບິ່ງ View, ເພີ່ມ, ຫຼືລຶບໃບອະນຸຍາດ.

ຄຸນນະສົມບັດໃຫມ່ແລະການປ່ຽນແປງ

ພາກນີ້ອະທິບາຍລັກສະນະຕ່າງໆໃນແຕ່ລະໂມດູນຂອງ Juniper Paragon Automation Release 24.1.
ການຕິດຕັ້ງແລະຍົກລະດັບ Paragon

• Red Hat Enterprise Linux (RHEL) 8.10—Paragon Automation Release 24.1 ມີຄຸນສົມບັດທີ່ຈະເຮັດວຽກກັບ RHEL 8.10.
  [ເບິ່ງ ຄວາມຕ້ອງການເບື້ອງຕົ້ນການຕິດຕັ້ງໃນ Red Hat Enterprise Linux.]
• ດໍາເນີນການຄໍາສັ່ງ utility paragon CLI ເປັນຜູ້ໃຊ້ທີ່ບໍ່ແມ່ນ root - ເລີ່ມຕົ້ນໃນ Paragon Automation Release 24.1, ຜູ້ໃຊ້ທີ່ບໍ່ແມ່ນ root ທີ່ມີສິດທິພິເສດ superuser (sudo) ສາມາດດໍາເນີນການຄໍາສັ່ງ paragon CLI utility ເພື່ອວິເຄາະ, ສອບຖາມ, ແລະ debug ການຕັ້ງຄ່າ Paragon Automation.
  [ເບິ່ງ ແກ້ໄຂບັນຫາການໃຊ້ paragon CLI Utility.]

Paragon Pathfinder

• ນະໂຍບາຍການກຳນົດເສັ້ນທາງຂອງພາກສ່ວນໃນອຸປະກອນ Cisco IOS XR—ເລີ່ມຕົ້ນໃນ Paragon Automation Release 24.1, ທ່ານສາມາດສະໜອງນະໂຍບາຍການກຳນົດເສັ້ນທາງຂອງພາກສ່ວນໃນອຸປະກອນ Cisco IOS XR ໂດຍໃຊ້ NETCONF ເປັນວິທີການສະໜອງ.

ເວທີພື້ນຖານ
ພວກເຮົາຍັງບໍ່ໄດ້ເພີ່ມຄຸນສົມບັດໃຫມ່ໃດໆທີ່ກ່ຽວຂ້ອງກັບເວທີພື້ນຖານໃນ Paragon Automation Release 24.1.
Paragon Insights
ພວກເຮົາຍັງບໍ່ໄດ້ເພີ່ມຄຸນສົມບັດໃຫມ່ໃດໆທີ່ກ່ຽວຂ້ອງກັບ Paragon Insights ໃນ Paragon Automation Release 24.1.
Paragon Planner
ພວກເຮົາບໍ່ໄດ້ເພີ່ມຄຸນສົມບັດໃໝ່ໃດໆທີ່ກ່ຽວຂ້ອງກັບ Paragon Planner ໃນ Paragon Automation Release 24.1.
ໝາຍເຫດ: Paragon Planner Web ແອັບພລິເຄຊັນເປັນຄຸນສົມບັດເບຕ້າຢູ່ໃນ Paragon Automation Release 24.1.

ລັກສະນະພິເສດ

ພາກສ່ວນນີ້ສະແດງລາຍການຄຸນສົມບັດທີ່ຖືກຍົກເລີກ ຫຼືສໍາລັບການຖອນການສະຫນັບສະຫນູນຈາກ Paragon
Automaton Release 24.1.
• Grafana UI
ທ່ານບໍ່ສາມາດເຂົ້າເຖິງ Grafana UI ຈາກ Paragon Automation. ເພື່ອເຂົ້າເຖິງ Grafana UI, ທ່ານຕ້ອງ:

1. ຕິດຕັ້ງ Grafana.
   ເບິ່ງ ເອກະສານ Grafana ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມ.
2. ເປີດພອດ TSDB ໂດຍການແລ່ນຄຳສັ່ງ /var/local/healthbot/healthbot tsdb start-services.

ໝາຍເຫດ: ໃນ Paragon Automation, ພອດ TSDB ບໍ່ຖືກເປີດເຜີຍໂດຍຄ່າເລີ່ມຕົ້ນ. ເພື່ອໃຊ້ເຄື່ອງມືພາຍນອກເຊັ່ນ Grafana, ທ່ານຈໍາເປັນຕ້ອງດໍາເນີນການສອບຖາມກັບ TSDB ໂດຍກົງ (ແລະບໍ່ແມ່ນຜ່ານ APIs) ເພື່ອເປີດເຜີຍພອດ TSDB.

ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມ, ເບິ່ງ ສໍາຮອງຂໍ້ມູນແລະການຟື້ນຟູ TSDB.
• ຕາຕະລາງ

ບັນຫາທີ່ຮູ້ຈັກ

ພາກນີ້ສະແດງບັນຫາທີ່ຮູ້ຈັກໃນ Juniper Paragon Automation Release 24.1

ການຕິດຕັ້ງ

• ໃນເວລາທີ່ທ່ານສະຫນອງເຄື່ອງ virtual (VMs) ໃນເຊີບເວີ VMware ESXi, ຖ້າທ່ານເພີ່ມແຜ່ນເກັບຂໍ້ມູນບລັອກກ່ອນທີ່ຈະເພີ່ມແຜ່ນທີ່ມີ OS ພື້ນຖານ, Ceph ບາງຄັ້ງກໍານົດໄດເວີທີ່ບໍ່ຖືກຕ້ອງແລະສ້າງກຸ່ມໂດຍໃຊ້ໄດທີ່ບໍ່ຖືກຕ້ອງ, ສົ່ງຜົນໃຫ້ OS ພື້ນຖານເປັນ. ຖືກທໍາລາຍ.
  ການແກ້ໄຂບັນຫາ: ເພີ່ມແຜ່ນທໍາອິດເປັນ OS ພື້ນຖານ (ໄດຂະຫນາດໃຫຍ່ກວ່າ) ແລະຫຼັງຈາກນັ້ນເພີ່ມແຜ່ນເກັບຂໍ້ມູນບລັອກຂະຫນາດນ້ອຍກວ່າ.
• ໃນກໍລະນີທີ່ບໍ່ມີຖານຂໍ້ມູນຊຸດເວລາ (TSDB) HA replication, ຖ້າ node ພະນັກງານ Kubernetes ທີ່ໃຊ້ pod TSDB ຫຼຸດລົງ, ເຖິງແມ່ນວ່າມີຄວາມອາດສາມາດໃນ pod, ບໍລິການ TSDB ບໍ່ໄດ້ຖືກ spun ຂຶ້ນໃນ node ໃຫມ່. ນີ້ແມ່ນຍ້ອນວ່າຂໍ້ມູນຈໍານວນຫຼວງຫຼາຍຈະຕ້ອງຖືກໂອນໄປຫາຂໍ້ໃຫມ່.
  ການແກ້ໄຂ: ໃນກໍລະນີຂອງຄວາມລົ້ມເຫຼວຂອງເຄື່ອງແມ່ຂ່າຍຫຼືການເກັບຮັກສາ hosting ເປັນຕົວຢ່າງ TSDB, ທ່ານສາມາດສ້າງເຄື່ອງແມ່ຂ່າຍໃຫມ່ຫຼືອົງປະກອບທີ່ເສຍຫາຍ.

ຖ້າປັດໄຈການຈໍາລອງຖືກຕັ້ງເປັນ 1, ຫຼັງຈາກນັ້ນຂໍ້ມູນ TSDB ສໍາລັບຕົວຢ່າງນັ້ນຈະສູນເສຍ. ໃນກໍລະນີດັ່ງກ່າວ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ເອົາ node TSDB ລົ້ມເຫລວຈາກ Paragon Automation. ເພື່ອເອົາ TSDB Node ທີ່ລົ້ມເຫລວ:

1. ໃນ Paragon Automation GUI, ເລືອກການຕັ້ງຄ່າ > Insights Settings.
   ໜ້າການຕັ້ງຄ່າຄວາມເຂົ້າໃຈຈະປາກົດຂຶ້ນ.
2. ຄລິກແຖບ TSDB ເພື່ອ view ໜ້າແຖບການຕັ້ງຄ່າ TSDB.
3. ເພື່ອລຶບ node ທີ່ລົ້ມເຫລວ, ໃນຫນ້າແຖບການຕັ້ງຄ່າ TSDB, ໃຫ້ຄລິກໃສ່ X ຖັດຈາກຊື່ຂອງ node TSDB ລົ້ມເຫລວ.
   ໝາຍເຫດ: ພວກເຮົາແນະນໍາໃຫ້ທ່ານລຶບໂຫນດ TSDB ໃນລະຫວ່າງປ່ອງຢ້ຽມການບໍາລຸງຮັກສາເນື່ອງຈາກບາງການບໍລິການຈະຖືກເປີດໃຫມ່ແລະ Paragon Automation GUI ຈະບໍ່ຕອບສະຫນອງໃນຂະນະທີ່ການເຮັດວຽກ TSDB ຖືກປະຕິບັດ.
4. ກົດ Save and Deploy.
5. ຖ້າການປ່ຽນແປງບໍ່ຖືກນຳໃຊ້ ແລະຫາກເຈົ້າພົບຂໍ້ຜິດພາດໃນຂະນະທີ່ກຳລັງນຳໃຊ້, ເປີດໃຊ້ປຸ່ມ Force toggle ແລະເຮັດການປ່ຽນແປງໂດຍການຄລິກ Save and Deploy. ໂດຍການເຮັດດັ່ງນັ້ນ, ລະບົບຈະບໍ່ສົນໃຈຄວາມຜິດພາດທີ່ພົບໃນຂະນະທີ່ປັບການຕັ້ງຄ່າ TSDB.

• ຖ້າທ່ານຖອນການຕິດຕັ້ງ Paragon Automation ຢ່າງສົມບູນ, ທ່ານຍັງຕ້ອງຮັບປະກັນວ່າໄດເລກະທໍລີ /var/lib/rook ຖືກໂຍກຍ້າຍອອກຢູ່ໃນທຸກ nodes, ແລະອຸປະກອນ Ceph block ທັງຫມົດຖືກເຊັດ.
  ວິທີແກ້ໄຂບັນຫາ: ເບິ່ງ ການແກ້ໄຂບັນຫາ Ceph ແລະ Rook > ສ້ອມແປງ Disk ທີ່ລົ້ມເຫລວ ພາກສ່ວນໃນຄູ່ມືການຕິດຕັ້ງອັດຕະໂນມັດ Paragon.
• ໃນຂະນະທີ່ການຕິດຕັ້ງ Paragon Automation ໂດຍໃຊ້ວິທີຊ່ອງຫວ່າງທາງອາກາດ, ຂໍ້ຜິດພາດຕໍ່ໄປນີ້ເກີດຂື້ນ:

ການແກ້ໄຂ: ແກ້ໄຂຕົວແປການຕັ້ງຄ່າຕໍ່ໄປນີ້ໃນ config-dir/config.yml file ແລະຫຼັງຈາກນັ້ນຕິດຕັ້ງ Paragon Automation ໂດຍໃຊ້ວິທີການຊ່ອງຫວ່າງທາງອາກາດ:

ທົ່ວໄປ

• ຜົນໄດ້ຮັບຄໍາສັ່ງ deploy-federated-exchange ສະແດງວ່າການຕິດຕັ້ງລົ້ມເຫລວໃນເວລາທີ່ທ່ານກໍາຫນົດຄ່າການຟື້ນຕົວໄພພິບັດໃນການນໍາໃຊ້ສອງ cluster. ທ່ານສາມາດບໍ່ສົນໃຈຂໍ້ຄວາມທີ່ລົ້ມເຫລວແຕ່ທ່ານຕ້ອງປະຕິບັດຄໍາສັ່ງຕໍ່ໄປນີ້ຢູ່ໃນທຸກ nodes ຕົ້ນຕໍຂອງທັງສອງ clusters:ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ເມື່ອຄວາມລົ້ມເຫລວຜົນກະທົບຕໍ່ທັງສອງຄູ່ຂອງ LSPs ທີ່ມີຄວາມຫຼາກຫຼາຍ, Path Computation Server (PCS) ຈະບໍ່ນໍາທາງ LSPs ໄປຕາມເສັ້ນທາງລະດັບຄວາມຫຼາກຫຼາຍຫນ້ອຍຫຼືໄປຕາມເສັ້ນທາງທີ່ບໍ່ມີຄວາມຫຼາກຫຼາຍ. LSPs ບໍ່ໄດ້ຖືກສົ່ງຕໍ່ຈົນກ່ວາ PCS ສາມາດຊອກຫາເສັ້ນທາງທີ່ກົງກັບລະດັບຄວາມຫຼາກຫຼາຍທີ່ໄດ້ກໍານົດໄວ້.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ
• ເມື່ອຄວາມລົ້ມເຫຼວມີຜົນກະທົບທັງສອງຄູ່ຂອງ LSPs ທີ່ຫຼາກຫຼາຍ, Path Computation Server (PCS) ຈະບໍ່ນໍາທາງ LSPs ຕາມເສັ້ນທາງທີ່ບໍ່ຫຼາກຫຼາຍ. LSPs ບໍ່ໄດ້ຖືກສົ່ງຕໍ່ຈົນກ່ວາ PCS ສາມາດຊອກຫາເສັ້ນທາງທີ່ກົງກັບລະດັບຄວາມຫຼາກຫຼາຍທີ່ໄດ້ກໍານົດໄວ້.
  ການແກ້ໄຂບັນຫາ: ເອົາອອກ ແລະນຳໃຊ້ກຸ່ມຄວາມຫຼາກຫຼາຍຄືນໃໝ່.
• ຄ່າເກນການປ່ຽນແປງຂັ້ນຕ່ຳພາຍໃຕ້ການຕັ້ງຄ່າຂະໜາດແບນວິດຂອງ subLSP container ແມ່ນສະແດງເປັນ 0 ເຖິງວ່າຈະມີການຕັ້ງຄ່າມັນຢູ່ໃນ container. ພາຍໃຕ້ເງື່ອນໄຂປົກກະຕິ, ບໍ່ມີຜົນກະທົບໃດໆຕໍ່ຂະຫນາດແບນວິດຂອງ subLSP ຍ້ອນວ່າວຽກງານຂະຫນາດແບນວິດດຶງເອົາຄ່ານີ້ຈາກຖັງແທນ subLSP. ຢ່າງໃດກໍຕາມ, ໃນບາງສະຖານະການ, ມັນເປັນໄປໄດ້ວ່າ subLSP ສາມາດຖືກປັບຂະຫນາດເປັນມູນຄ່າແບນວິດໃຫມ່ໃນເວລາທີ່ກໍານົດຂອບເຂດການປ່ຽນແປງຕໍາ່ສຸດທີ່ບໍ່ໄດ້ລະເມີດ.
  ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບບັນຫານີ້, ຕິດຕໍ່ Juniper Networks Technical Assistance Center (JTAC).
• ໃນ​ລະ​ຫວ່າງ​ການ​ຂະ​ຫນາດ​ແບນ​ວິດ, LSP ຮອງ​ທີ່​ມີ​ການ​ເຄື່ອນ​ໄຫວ​ທີ່​ມີ​ຂະ​ຫນາດ​ແບນ​ວິດ​ທີ່​ເປີດ​ໃຊ້​ງານ​ອາດ​ຈະ​ບໍ່​ໄດ້​ຮັບ​ການ​ປັບ​ຂະ​ຫນາດ. ເມື່ອບັນຫານີ້ເກີດຂື້ນ, ການໃຊ້ RSVP ຂອງການເຊື່ອມຕໍ່ໃນເສັ້ນທາງທີສອງອາດຈະຖືກປັບປຸງບໍ່ຖືກຕ້ອງ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ການປ່ຽນແປງການຕັ້ງຄ່າ Paragon Pathfinder (ການຕັ້ງຄ່າ > ການຕັ້ງຄ່າເຄືອຂ່າຍ) ໂດຍໃຊ້ UI ອາດຈະຕ້ອງການຄວາມພະຍາຍາມຫຼາຍກວ່າຫນຶ່ງຄັ້ງເພື່ອໃຫ້ການດັດແກ້ມີຜົນ. ທ່ານອາດຈະຕ້ອງຄລິກບັນທຶກຫຼາຍກວ່າຫນຶ່ງຄັ້ງ.
  ການແກ້ໄຂບັນຫາ: ການປ່ຽນແປງດຽວກັນສາມາດເຮັດໄດ້ໂດຍໃຊ້ cMGD CLI ທີ່ສາມາດເຂົ້າເຖິງໄດ້ຈາກແມ່ບົດທີ່ແລ່ນຄໍາສັ່ງ pf-cmgd.
• ພາຍໃຕ້ເງື່ອນໄຂສະເພາະໃດຫນຶ່ງໃນລະຫວ່າງການປັບຕົວບັນຈຸເປັນປົກກະຕິ, ຫນຶ່ງຫຼືຫຼາຍ subLSPs ບັນຈຸທີ່ຄວນຈະຖືກໂຍກຍ້າຍອອກຈະຍັງຄົງຢູ່. subLSPs ຕູ້ຄອນເທນເນີເຫຼົ່ານີ້ຈະຍັງຄົງຢູ່ໃນເຄືອຂ່າຍຍ້ອນວ່າ LSPs ເອກະລາດບໍ່ກ່ຽວຂ້ອງກັບຕົວບັນຈຸ. ຄວາມບໍ່ກົງກັນໃນຈໍານວນ subLSPs ຂອງ container ທີ່ລະບຸໄວ້ໃນຖັນ subLSPs ພາຍໃຕ້ແຖບ Container LSP ແລະຈໍານວນຕົວຈິງຂອງ LSPs ທີ່ມີຊື່ຂອງ container ເປັນຄໍານໍາຫນ້າພາຍໃຕ້ແຖບ Tunnel, ສາມາດຖືວ່າເປັນຕົວຊີ້ບອກຂອງບັນຫານີ້.
  ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບບັນຫານີ້, ຕິດຕໍ່ Juniper Networks Technical Assistance Center (JTAC).
• ຕູ້ຄອນເທນເນີ LSP ສາມາດຖືກຕັ້ງຄ່າດ້ວຍການຕັ້ງຄ່າຂະຫນາດແບນວິດທີ່ສືບທອດໂດຍ subLSPs ຂອງມັນ. ພາຍໃຕ້ສະຖານະການບາງຢ່າງ, ເມື່ອຜູ້ໃຊ້ປິດການໃຊ້ງານຕົວເລືອກຂະຫນາດແບນວິດໃນຖັງຫຼັງຈາກເປີດໃຊ້ມັນໃນອະດີດ, ມັນຈະບໍ່ຖືກປິດໃຊ້ງານໃນ subLSPs ທີ່ມີຢູ່.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ການແກ້ໄຂຄູ່ມືຂອງ subLSP ຂອງ container ຈະນໍາໄປສູ່ການເພີ່ມຂໍ້ມູນໃສ່ວັດຖຸ LSP. ດັ່ງນັ້ນ, ບັນຫາຕໍ່ໄປນີ້ອາດຈະເກີດຂຶ້ນ:
• ຖ້າຕູ້ຄອນເທນເນີຖືກປັບຂະຫນາດແບນວິດແລະກໍານົດຂອບເຂດການປ່ຽນແປງຕໍາ່ສຸດທີ່ທີ່ບໍ່ແມ່ນສູນ, subLSP ສະເພາະສາມາດໄດ້ຮັບການປັບຂະຫນາດເຖິງແມ່ນວ່າການຈະລາຈອນຜ່ານ subLSP ບໍ່ເກີນແບນວິດສັນຍານຂອງມັນໂດຍຢ່າງຫນ້ອຍຄ່າຂອບເຂດການປ່ຽນແປງຕໍາ່ສຸດທີ່.
• subLSP ສາມາດສິ້ນສຸດມີການຕັ້ງຄ່າຂະຫນາດແບນວິດທີ່ແຕກຕ່າງກັນກ່ວາບັນຈຸຖ້າການຕັ້ງຄ່າຂະຫນາດແບນວິດຂອງຖັງຖືກດັດແກ້ຕໍ່ມາ.
• ຄວາມລົ້ມເຫຼວຂອງການໂຍກຍ້າຍຂອງ subLSP ໃນລະຫວ່າງການປົກກະຕິຂອງ container ໃນເວລາທີ່ bandwidth ຫຼຸດລົງຕ່ໍາກວ່າການລວມແບນວິດ.
  ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບບັນຫານີ້ແລະຄໍາແນະນໍາທີ່ຈະເອົາຂໍ້ມູນເພີ່ມເຕີມທີ່ໄດ້ຮັບການເພີ່ມເຂົ້າໄປໃນສະຖານະພາຍໃນ, ຕິດຕໍ່ Juniper Networks Technical Assistance Center (JTAC).
• ພາຍໃຕ້ສະຖານະການບາງຢ່າງເຊັ່ນ: ຄວາມລົ້ມເຫຼວຂອງການເຮັດໃຫ້ຖັງເປັນປົກກະຕິໃນການຂາດເສັ້ນທາງທີ່ມີຢູ່, ສະຖານະພາຍໃນເພີ່ມເຕີມຈະຖືກເພີ່ມໃສ່ວັດຖຸ subLSP ບັນຈຸທີ່ສາມາດນໍາໄປສູ່ບັນຫາຕໍ່ໄປນີ້:
• ຖ້າຕູ້ຄອນເທນເນີຖືກປັບຂະຫນາດແບນວິດແລະກໍານົດຂອບເຂດການປ່ຽນແປງຕໍາ່ສຸດທີ່ທີ່ບໍ່ແມ່ນສູນ, subLSP ສະເພາະສາມາດໄດ້ຮັບການປັບຂະຫນາດເຖິງແມ່ນວ່າການຈະລາຈອນຜ່ານ subLSP ບໍ່ເກີນແບນວິດສັນຍານຂອງມັນໂດຍຢ່າງຫນ້ອຍຄ່າຂອບເຂດການປ່ຽນແປງຕໍາ່ສຸດທີ່.
• subLSP ສາມາດສິ້ນສຸດມີການຕັ້ງຄ່າຂະຫນາດແບນວິດທີ່ແຕກຕ່າງກັນກ່ວາບັນຈຸຖ້າການຕັ້ງຄ່າຂະຫນາດແບນວິດຂອງຖັງຖືກດັດແກ້ຕໍ່ມາ.
• ຄວາມລົ້ມເຫຼວຂອງການໂຍກຍ້າຍຂອງ subLSP ໃນລະຫວ່າງການປົກກະຕິຂອງ container ໃນເວລາທີ່ bandwidth ຫຼຸດລົງຕ່ໍາກວ່າການລວມແບນວິດ.

ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບບັນຫານີ້ແລະຄໍາແນະນໍາທີ່ຈະເອົາຂໍ້ມູນເພີ່ມເຕີມທີ່ໄດ້ຮັບການເພີ່ມເຂົ້າໄປໃນສະຖານະພາຍໃນ, ຕິດຕໍ່ Juniper Networks Technical Assistance Center (JTAC).

• ເມື່ອໜຶ່ງ ຫຼືຫຼາຍໂຫນດໃນກຸ່ມ Kubernetes ທີ່ເຮັດວຽກບໍ່ສາມາດໃຊ້ໄດ້, ມັນອາດຈະສົ່ງຜົນໃຫ້ເກີດພຶດຕິກຳທີ່ບໍ່ຄາດຄິດຕໍ່ໄປນີ້:
• ສະ​ຖາ​ນະ PCEP ຂອງ​ຂໍ້​ມູນ​ທັງ​ຫມົດ​ສະ​ແດງ​ໃຫ້​ເຫັນ​ເປັນ​ລົງ​ເຖິງ​ແມ່ນ​ວ່າ​ສະ​ຖາ​ນະ​ການ​ເຊື່ອມ​ຕໍ່ PCEP ແມ່ນ​ຂຶ້ນ​ຢູ່​ໃນ router​.
• ເຄືອຂ່າຍ topology ບໍ່ສະແດງຢູ່ໃນ UI.
  ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບບັນຫານີ້, ຕິດຕໍ່ Juniper Networks Technical Assistance Center (JTAC).
• Paragon Pathfinder ສາມາດຄິດໄລ່ເສັ້ນທາງທີ່ລະເມີດຂໍ້ຈໍາກັດ hop ສູງສຸດທີ່ຖືກກໍານົດໄວ້ໃນອຸໂມງ. ສະຖານະການເຫຼົ່ານີ້ອະທິບາຍວິທີການຈໍາກັດ hop ສູງສຸດແມ່ນ voided:
• ເມື່ອ Path Computation Server (PCS) restarts, LSP ລົງແມ່ນຈັດໃຫ້ໂດຍບໍ່ໄດ້ພິຈາລະນາຂໍ້ຈໍາກັດສູງສຸດ.
• ໃນລະຫວ່າງຄວາມລົ້ມເຫຼວຂອງເຄືອຂ່າຍ, LSP ຖືກປ່ຽນເສັ້ນທາງໂດຍບໍ່ໄດ້ພິຈາລະນາຂໍ້ຈໍາກັດສູງສຸດຂອງ hop.
• ໃນລະຫວ່າງການເພີ່ມປະສິດທິພາບຂອງເສັ້ນທາງ, LSP ໄດ້ຖືກປັບປຸງໃຫ້ດີທີ່ສຸດໂດຍບໍ່ມີການພິຈາລະນາຂໍ້ຈໍາກັດສູງສຸດຂອງ hop.
  ການແກ້ໄຂບັນຫາ: ໃຊ້ທາງເລືອກ reprovision ຖ້າເສັ້ນທາງທາງເລືອກທີ່ບໍ່ລະເມີດຂໍ້ຈໍາກັດທີ່ກໍານົດໄວ້.
• ເສັ້ນທາງທີ່ຄິດໄລ່ໂດຍ Paragon Pathfinder ສໍາລັບການສະແຕນບາຍ LSP ທີ່ມີຂໍ້ຈໍາກັດສູງສຸດຂອງ hop ສາມາດລະເມີດຂໍ້ຈໍາກັດທີ່ກໍານົດໄວ້.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ມີຄວາມເປັນໄປໄດ້ທີ່ PCS ບໍ່ສາມາດຊອກຫາ LSP ທີ່ມີຄວາມຫຼາກຫຼາຍຂອງການເຊື່ອມໂຍງໃນ topology ທີ່ມີການເຊື່ອມຕໍ່ຂະຫນານຫຼາຍລະຫວ່າງ nodes.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ເມື່ອເຊດຊັນ PCEP ຖືກປິດໃຊ້ງານ, ສະຖານະການປະຕິບັດການ LSP ຈະຍ້າຍໄປຢູ່ໃນສະຖານະທີ່ບໍ່ຮູ້ຈັກຫຼັງຈາກແລ່ນເກັບອຸປະກອນ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ລິ້ງອາດຈະຫາຍໄປເມື່ອສ້າງໜ້າວຽກການຈັດເກັບເຄືອຂ່າຍ.
  ການແກ້ໄຂບັນຫາ: ສ້າງໜ້າວຽກການຈັດເກັບເຄືອຂ່າຍໃໝ່.
• ບໍ່ສາມາດສົ່ງຕໍ່ຄວາມຕ້ອງການ VPN ໄດ້ເນື່ອງຈາກບັນຫາໃນເຄືອຂ່າຍ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ສັນຍານເຕືອນບໍ່ຕອບສະໜອງເມື່ອອຸປະກອນ Cisco ຖືກຕັ້ງຄ່າໃນເບື້ອງຕົ້ນດ້ວຍ NETCONF ຢູ່ພອດ 22.
  ການແກ້ໄຂ: ແກ້ໄຂພອດ NETCONF ໃນອຸປະກອນ Cisco ຂອງເຈົ້າເປັນ ແລະໃຫ້ແນ່ໃຈວ່າການປ່ຽນແປງໄດ້ຖືກບັນທຶກໄວ້. ຫຼັງຈາກນີ້, ປ່ຽນການຕັ້ງຄ່າພອດກັບຄືນສູ່ພອດ 22.
• ເມື່ອທ່ານເພີ່ມຄວາມຕ້ອງການ multicast ໃນ GUI, node Z field ແມ່ນຫວ່າງເປົ່າ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ເມື່ອທ່ານເພີ່ມອຸໂມງໃໝ່ຫຼາຍອັນ, ຄ່າການຈະລາຈອນຈາກອຸໂມງທີ່ຖືກລຶບໄປກ່ອນໜ້ານີ້ (ທີ່ເກັບໄວ້ໃນບ່ອນເກັບມ້ຽນ) ຈະສະແດງຂຶ້ນ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ໃນເວລາທີ່ທ່ານເພີ່ມ tunnels ຫຼາກຫຼາຍຊະນິດໃຫມ່, ບາງຄັ້ງມູນຄ່າການຈະລາຈອນຈາກ tunnels ທີ່ຖືກລຶບກ່ອນຫນ້ານີ້ (ທີ່ຖືກເກັບໄວ້ໃນຖານຄວາມຈໍາ) ຈະຖືກສະແດງ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• Toposerver ບໍ່ຈະແຈ້ງ ຫຼືປັບປຸງ topology ຫຼັງຈາກສູນເສຍການເຊື່ອມຕໍ່ກັບພອດ BMP.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ເມື່ອການເຊື່ອມຕໍ່ຖືກລົງ, Paragon Pathfinder ບໍ່ໄດ້ປ່ຽນເສັ້ນທາງ SR LSP ທີ່ຖືກມອບໝາຍດ້ວຍວັດຖຸເສັ້ນທາງທີ່ມັກ (ERO) ແລະເສັ້ນທາງໂດຍວິທີການກໍານົດເສັ້ນທາງອຸປະກອນ.
  ການແກ້ໄຂບັນຫາ: ໃຊ້ວິທີການກໍານົດເສັ້ນທາງເລີ່ມຕົ້ນ.
• ຖ້າທ່ານດໍາເນີນການຈໍາລອງໂດຍກົງຫຼັງຈາກທີ່ທ່ານປະຕິບັດການອອກແບບຕົ້ນໄມ້ Multicast ທີ່ມີຄວາມຫຼາກຫຼາຍ, ບົດລາຍງານໃນ Tunnel Traffic on Links (Tunnel Layer Simulation Report > Peak Network Statistics) ແມ່ນບໍ່ຖືກຕ້ອງ.
  Workaround: ບັນທຶກເຄືອຂ່າຍຫຼັງຈາກທີ່ທ່ານປະຕິບັດການອອກແບບຕົ້ນໄມ້ Multicast ທີ່ມີຄວາມຫຼາກຫຼາຍແລະປິດມັນ. ເປີດເຄືອຂ່າຍຄືນໃໝ່ແລ້ວເປີດການຈຳລອງ.
• ໃນຂະນະທີ່ການຈໍາລອງສະຖານະການຄວາມລົ້ມເຫຼວ (ເຄື່ອງມື > ທາງເລືອກ > ການຈໍາລອງຄວາມລົ້ມເຫລວ), ຖ້າທ່ານດໍາເນີນການຈໍາລອງຄວາມລົ້ມເຫລວຫຼາຍຄັ້ງທໍາອິດແລະຫຼັງຈາກນັ້ນດໍາເນີນການຈໍາລອງຄວາມລົ້ມເຫລວດຽວຫຼັງຈາກນັ້ນ, ບົດລາຍງານໃນ Tunnel Traffic on Links (Tunnel Layer Simulation Report > Peak Network Statistics) ບໍ່ຖືກຕ້ອງ. ບົດລາຍງານສະແດງຄ່າຈໍາລອງຄວາມລົ້ມເຫລວຫຼາຍອັນແທນທີ່ຈະເປັນຄວາມລົ້ມເຫລວດຽວ.
  ການແກ້ໄຂບັນຫາ: ຍົກເລີກການເລືອກຕົວເລືອກທັງໝົດໃນແຖບຄວາມລົ້ມເຫຼວຫຼາຍອັນ ກ່ອນທີ່ຈະຈຳລອງສະຖານະການລົ້ມເຫລວອັນດຽວ.
• ບົດລາຍງານການຈໍາລອງການນໍາໃຊ້ການເຊື່ອມໂຍງອາດຈະສະແດງຄ່າທາງລົບໃນລະຫວ່າງສະຖານະການລົ້ມເຫຼວສອງເທົ່າ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ເມື່ອຊື່ໂຮດຂອງອຸປະກອນຖືກປ່ຽນ, ການປ່ຽນແປງຈະບໍ່ຖືກສະທ້ອນໃນທົ່ວທຸກຖານຂໍ້ມູນ.

ການແກ້ໄຂບັນຫາ: ດໍາເນີນຂັ້ນຕອນຕໍ່ໄປນີ້ເພື່ອໃຫ້ຊື່ໂຮດອຸປະກອນໃຫມ່ຖືກສະທ້ອນໃນທົ່ວຖານຂໍ້ມູນແລະອົງປະກອບທັງຫມົດ.

1. ກ່ອນການປ່ຽນຊື່ໂຮສ, ເອົາອຸປະກອນອອກຈາກທຸກກຸ່ມອຸປະກອນ (ຕົວຄວບຄຸມ ຫຼືເຄື່ອງຫຼິ້ນອື່ນໆ).
2. ໃຫ້ແນ່ໃຈວ່າການອ້າງອີງອຸປະກອນຖືກລຶບອອກຈາກອົງປະກອບ Paragon Automation ທີ່ແຕກຕ່າງກັນທັງໝົດ. ໄປທີ່ໜ້າການຕັ້ງຄ່າ > ອຸປະກອນ.
   ກ. ເລືອກອຸປະກອນ.
   ຂ. ຄລິກໄອຄອນຖັງຂີ້ເຫຍື້ອເພື່ອລຶບອຸປະກອນ. ໜ້າລຶບອຸປະກອນຈະປາກົດຂຶ້ນ.
   ຄ. ເລືອກ Force Delete ແລະກົດ Yes.
3. ຢູ່ເທິງອຸປະກອນອີກຄັ້ງ, ໂດຍໃຊ້ຂັ້ນຕອນການເປີດອຸປະກອນຈາກໜ້າການຕັ້ງຄ່າ > ອຸປະກອນ.
   ດຽວນີ້ອຸປະກອນຄວນຈະຖືກເປີດໃຊ້ດ້ວຍຊື່ເຈົ້າພາບໃໝ່. ຄຸນສົມບັດຂອງອຸປະກອນໂດຍສະເພາະລະບົບ-id (ທີ່ສໍາຄັນສໍາລັບການໄດ້ຮັບສາຍນ້ໍາ JTI) ຄວນຈະໄດ້ຮັບການປັບປຸງ.
4. ເພີ່ມອຸປະກອນທີ່ມີຊື່ໂຮດໃຫມ່ກັບຄືນໄປຫາກຸ່ມອຸປະກອນ.
5. (ທາງເລືອກ) ກວດສອບສະຖິຕິອຸປະກອນທັງໝົດໃນ Influxdb ໂດຍໃຊ້ Grafana ຫຼືຢູ່ໃນອຸປະກອນ CLI. ຖານຂໍ້ມູນຄວນໄດ້ຮັບການປັບປຸງດ້ວຍຊື່ໂຮດໃຫມ່.

• ວິທີການຈັດຫາ Network Configuration Protocol (NETCONF) ສໍາລັບ point-to-multipoint (P2MP) LSPs ແມ່ນບໍ່ຮອງຮັບໃນເຣົາເຕີ Cisco IOS-XR.
• ໃນເຣົາເຕີ Cisco IOS-XR, ສະຖານະຍ່ອຍຂອງ P2MP ບໍ່ຮອງຮັບໃນສະຖານະການຕັ້ງຄ່າສຳລັບ CLIprovisioned P2MP LSPs.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• Junos OS Release 22.4R1 ແລະຕໍ່ມາມີຂໍ້ຈໍາກັດກັບ SR-TE LSPs.
  ສໍາລັບກອງປະຊຸມ PCEP ທີ່ຈະສ້າງຕັ້ງຂຶ້ນ, ທ່ານຕ້ອງປິດຄຸນສົມບັດ multipath ໂດຍໃຊ້ຄໍາສັ່ງຕໍ່ໄປນີ້: set protocols pcep disable-multipath-capability Secondary path is not supported.
•  ຂໍ້ຄວາມເກົ່າຢູ່ໃນຄິວກໍາລັງຖືກດໍາເນີນການຫຼັງຈາກການເຊື່ອມຕໍ່ສະຫະພັນໄດ້ຖືກກູ້ຄືນ.
  ການແກ້ໄຂບັນຫາ: ກຳນົດເວລາໝົດອາຍຸຄິວລິ້ງສະຫະພັນໃກ້ກັບເວລາກວດພົບຄວາມລົ້ມເຫຼວຂອງການເຊື່ອມໂຍງຂອງສະຫະພັນ Toposerver (ຄ່າເລີ່ມຕົ້ນແມ່ນ 3*5s).
• ທ່ານບໍ່ສາມາດໃຊ້ວິທີການ NETCONF ແລະ Path Computation Element Protocol (PCEP) ເພື່ອສະໜອງ P2MP LSPs ສໍາລັບເຣົາເຕີ Cisco IOS-XR ໂດຍໃຊ້ Paragon Automation UI.
  ການແກ້ໄຂບັນຫາ. ສະໜອງ P2MP LSPs ໂດຍໃຊ້ CLI. ຫຼັງ​ຈາກ​ການ​ຕັ້ງ​ຄ່າ​ໄດ້​ຖືກ​ວິ​ເຄາະ​, ດໍາ​ເນີນ​ການ​ວຽກ​ງານ​ການ​ເກັບ​ກໍາ​ອຸ​ປະ​ກອນ​ເພື່ອ​ view LSPs.
•  ທ່ານ​ບໍ່​ສາ​ມາດ​ປິດ​ການ​ທໍາ​ງານ​ທຸງ​ທີ່​ມາ​ຂອງ​ຄວາມ​ຈິງ​ໃນ​ເວ​ລາ​ທີ່​ການ​ນໍາ​ໃຊ້​ຢູ່​ໃນ​ຮູບ​ແບບ​ທີ່​ປອດ​ໄພ​.
  ວິທີແກ້ໄຂບັນຫາ: ຣີສະຕາດພອດເຊີບເວີເພື່ອປິດການໃຊ້ງານທຸງແຫຼ່ງຄວາມຈິງໃນລະຫວ່າງໂໝດປອດໄພ.
• ເມື່ອທ່ານເລືອກເສັ້ນທາງສະຫຼັບປ້າຍກຳກັບທີ່ຖືກມອບໝາຍຫຼາຍອັນ (LSPs) ເປັນຂອງ router ingress ດຽວ ແລະຄລິກ Return Delegation to PCC, ພຽງແຕ່ຫນຶ່ງໃນ LSPs ກາຍເປັນອຸປະກອນຄວບຄຸມ. ບັນຫາໃນ Junos ເຮັດໃຫ້ເກີດສະຖານະການນີ້.
  ການແກ້ໄຂ: ເລືອກຫນຶ່ງ LSP ໃນເວລານັ້ນແລະຄລິກສົ່ງຄືນການມອບຫມາຍໃຫ້ PCC ເປັນສ່ວນບຸກຄົນສໍາລັບແຕ່ລະ LSP.
• ສະຖານະການປະຕິບັດການຂອງ SR-TE LSP ທີ່ຖືກມອບຫມາຍຍັງຄົງຫຼຸດລົງຫຼັງຈາກ node ຈຸດຫມາຍປາຍທາງຂອງມັນໄດ້ຖືກຄົ້ນພົບຄືນ.
  ການແກ້ໄຂບັນຫາ: ທ່ານຕ້ອງ sync ຮູບແບບເຄືອຂ່າຍຫຼັງຈາກ node ຈຸດຫມາຍປາຍທາງ SR-TE LSP ທີ່ໄດ້ຮັບມອບຫມາຍຖືກຄົ້ນພົບຄືນໃຫມ່.
• ເຊີບເວີ PCE ບໍ່ສາມາດເຊື່ອມຕໍ່ຫາ rabbitmq ຄືນໃໝ່ໄດ້ຫຼັງຈາກ rabbitmq ຖືກເປີດຄືນໃໝ່.
  ການແກ້ໄຂບັນຫາ: ຣີສະຕາດ ns-pceserver pod.
• ທ່ານບໍ່ສາມາດແກ້ໄຂການຕັ້ງຄ່າການແລກປ່ຽນການນໍາໃຊ້ຈາກ REST API/UI ໄດ້.
  ການແກ້ໄຂ: ແກ້ໄຂການຕັ້ງຄ່າການແລກປ່ຽນທີ່ໃຊ້ໂດຍສະຫະພັນໂດຍກົງຈາກ cMGD CLI ແລະປິດເປີດໂຕເຊີບເວີຄືນໃໝ່ເພື່ອໃຫ້ການປ່ຽນແປງມີຜົນ.
• Paragon Insights ແຜນທີ່ຊື່ (ຊື່ເຈົ້າພາບຫຼືທີ່ຢູ່ IP) ພາກສະຫນາມໃສ່ ID ອຸປະກອນ. ຢ່າງໃດກໍຕາມ, ຊື່ອຸປະກອນແມ່ນບໍ່ເປັນເອກະລັກອີກຕໍ່ໄປສໍາລັບເຫດຜົນດັ່ງຕໍ່ໄປນີ້:
• ໃນອຸປະກອນເຄື່ອງຈັກ Routing ຄູ່, “-reX” ຖືກຕໍ່ທ້າຍກັບຊື່ອຸປະກອນ.
• ແອັບພລິເຄຊັນພາກສ່ວນທີສາມເຊັ່ນ Anuta Atom ຕື່ມຊື່ໂດເມນໃສ່ຊື່ອຸປະກອນ.
  ນອກຈາກນັ້ນ, ການສ້າງແຜນທີ່ອຸປະກອນໂດຍຕົວລະບຸເອກະລັກທົ່ວໄປ (UUID) ແລະບໍ່ແມ່ນຊື່ໂຮດສາມາດເຮັດໃຫ້ເກີດບັນຫາກັບຂໍ້ມູນທີ່ GUI ສະແດງ.
  ການແກ້ໄຂບັນຫາ: ຕັ້ງຄ່າທີ່ຢູ່ IP ເພີ່ມເຕີມສໍາລັບການໂຕ້ຕອບ Ethernet ການຈັດການໃນອຸປະກອນໂດຍການລວມເອົາຄໍາຖະແຫຼງການຕົ້ນສະບັບເທົ່ານັ້ນໃນລະດັບລໍາດັບ [ດັດແກ້ກຸ່ມ]. ຫຼັງຈາກນັ້ນ, ທ່ານຈະຕ້ອງໃຊ້ທີ່ຢູ່ IP ເພີ່ມເຕີມນີ້ສໍາລັບການຂຶ້ນອຸປະກອນ. ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມ, ເບິ່ງ ການຈັດການການໂຕ້ຕອບ Ethernet.
• ຖ້າເຈົ້າໄດ້ອຸທິດ node ສໍາລັບ TSDB, ບາງບໍລິການ (ສໍາລັບ example, AtomDB, ZooKeeper, ແລະອື່ນໆ) ໃນ namespace ທົ່ວໄປທີ່ມີຊຸດ PersistentVolumeClaim ສາມາດໄດ້ຮັບຜົນກະທົບຖ້າ pods ທີ່ກ່ຽວຂ້ອງກໍາລັງແລ່ນຢູ່ໃນ node ທີ່ອຸທິດຕົນ. ນັ້ນແມ່ນ, ສະຖານະຂອງຝັກທີ່ແລ່ນຢູ່ໃນໂຫນດ TSDB ແມ່ນສະແດງຢູ່ສະເໝີ.
  ການແກ້ໄຂ: ເພື່ອຫຼີກເວັ້ນສະຖານະການນີ້, ໃນຂະນະທີ່ກໍານົດ node ສໍາລັບ TSDB, ໃຫ້ແນ່ໃຈວ່າ node ບໍ່ມີ pods ສໍາລັບການບໍລິການທີ່ອຸທິດຕົນທີ່ໃຊ້ PersistentVolumeClaim.
• ເມື່ອທ່ານຍົກເລີກການມອບໝາຍ LSP ທີ່ໄດ້ຮັບມອບໝາຍ, ແບນວິດທີ່ວາງແຜນໄວ້ຂອງ LSP ແມ່ນອີງໃສ່ແບນວິດທີ່ອຸປະກອນລາຍງານມາ ແທນທີ່ຈະເປັນມູນຄ່າການປ້ອນຂໍ້ມູນຂອງຜູ້ໃຊ້.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ໃນຂະນະທີ່ການເພີ່ມອຸປະກອນ, ຖ້າທ່ານລະບຸທີ່ຢູ່ IP ແຫຼ່ງທີ່ຖືກນໍາໃຊ້ແລ້ວໃນເຄືອຂ່າຍ, ທ່ານອາດຈະບໍ່ສາມາດເພີ່ມອຸປະກອນເຂົ້າໄປໃນກຸ່ມອຸປະກອນ, ນໍາໃຊ້ playbook, ພົບກັບຄວາມຜິດພາດທີ່ກ່ຽວຂ້ອງກັບການ ingest, ແລະອື່ນໆ.
  ການແກ້ໄຂບັນຫາ: ແກ້ໄຂທີ່ຢູ່ IP ແຫຼ່ງທີ່ຂັດແຍ້ງກັນ. ຄລິກໄອຄອນສະຖານະການນຳໃຊ້ ແລະເຮັດການປ່ຽນແປງ.
• ຖ້າທ່ານເລືອກແບບສອບຖາມທີ່ບັນທຶກໄວ້ໃນໜ້າໂມງປຸກ, ໂມງປຸກຈະຖືກກັ່ນຕອງໂດຍອີງໃສ່ຄຳຊອກຫາທີ່ບັນທຶກໄວ້. ແຕ່, ເສັ້ນສະແດງແລະວັນທີບໍ່ໄດ້ປັບປຸງ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ຖ້າທ່ານເພີ່ມອຸປະກອນທີ່ບໍ່ໄດ້ຈັດການຢູ່ໃນຫນ້າອຸປະກອນ ແລະຕໍ່ມາແກ້ໄຂຊື່ໂຮດຂອງອຸປະກອນທີ່ບໍ່ໄດ້ຈັດການ, ຊື່ເຈົ້າພາບຈະບໍ່ສະແດງຢູ່ໃນກຸ່ມອຸປະກອນ ແລະໃນ dashlet ອຸປະກອນໃນ Dashboard.
  ການແກ້ໄຂບັນຫາ: ທ່ານສາມາດເພີ່ມອຸປະກອນທີ່ບໍ່ສາມາດຈັດການໄດ້ໂດຍໃຊ້ຊື່ເຈົ້າພາບ ຫຼືທີ່ຢູ່ IP ຂອງອຸປະກອນ.
  ຖ້າທ່ານໄດ້ເພີ່ມອຸປະກອນທີ່ບໍ່ໄດ້ຈັດການໂດຍໃຊ້ຊື່ໂຮດ, ຫຼັງຈາກນັ້ນການລຶບອຸປະກອນທີ່ມີຢູ່ແລ້ວແລະເພີ່ມອຸປະກອນທີ່ມີຊື່ໂຮດໃຫມ່ແກ້ໄຂບັນຫາ.
  ຖ້າທ່ານໄດ້ເພີ່ມອຸປະກອນທີ່ບໍ່ສາມາດຈັດການໄດ້ໂດຍໃຊ້ທີ່ຢູ່ IP, ຫຼັງຈາກນັ້ນໃນກຸ່ມອຸປະກອນແລະ dashlet ອຸປະກອນໃນ Dashboard, ທ່ານຈໍາເປັນຕ້ອງລະບຸອຸປະກອນທີ່ບໍ່ໄດ້ຈັດການໂດຍອີງໃສ່ທີ່ຢູ່ IP ແລະບໍ່ແມ່ນຊື່ເຈົ້າພາບ.
• ໂດຍຄ່າເລີ່ມຕົ້ນ, ຕົວກອງ topology ປິດໃຊ້ງານ. ທ່ານບໍ່ສາມາດເປີດໃຊ້ຕົວກອງ topology ໂດຍໃຊ້ Paragon Automation GUI.
  ການແກ້ໄຂ: ສໍາລັບຂັ້ນຕອນການເປີດໃຊ້ຕົວກອງ topology, ເບິ່ງຫົວຂໍ້ Enable the Topology Filter Service.
• ສໍາລັບອຸປະກອນ Cisco IOS XR, ທ່ານບໍ່ສາມາດຟື້ນຟູການຕັ້ງຄ່າອຸປະກອນຈາກຫນ້າອຸປະກອນ. ທ່ານພຽງແຕ່ສາມາດສໍາຮອງຂໍ້ມູນການຕັ້ງຄ່າອຸປະກອນ.
  ການແກ້ໄຂບັນຫາ: ເພື່ອຟື້ນຟູການຕັ້ງຄ່າອຸປະກອນຂອງອຸປະກອນ Cisco IOS XR ຂອງທ່ານ:
  1. ໃນໜ້າການຕັ້ງຄ່າ > ອຸປະກອນ, ເລືອກອຸປະກອນ Cisco XR ແລະຄລິກເພີ່ມເຕີມ > ເວີຊັນການຕັ້ງຄ່າ.
  2. ຄັດລອກເວີຊັນການຕັ້ງຄ່າທີ່ທ່ານຕ້ອງການທີ່ຈະຟື້ນຟູ.
  3. ຟື້ນຟູການຕັ້ງຄ່າໂດຍໃຊ້ CLI.
• ຖ້າທ່ານໄດ້ເປີດໃຊ້ SSH ຂາອອກໃນລະດັບກຸ່ມອຸປະກອນ, ທ່ານບໍ່ສາມາດປິດການໃຊ້ງານ SSH ຂາອອກສໍາລັບອຸປະກອນຫນຶ່ງໃນກຸ່ມອຸປະກອນ.
  ການແກ້ໄຂບັນຫາ: ທ່ານສາມາດເປີດໃຊ້ຫຼືປິດການໃຊ້ງານ SSH ຂາອອກໃນອຸປະກອນໂດຍໃຊ້ MGD CLI ຫຼື Rest APIs. ເພື່ອປິດການໃຊ້ງານ SSH ຂາອອກ, ທ່ານຕ້ອງຕັ້ງທຸງປິດການໃຊ້ງານເປັນຖືກຕ້ອງ. ດໍາເນີນການຄໍາສັ່ງຕໍ່ໄປນີ້ໃນອຸປະກອນເພື່ອປິດການທໍາງານ SSH ຂາອອກໂດຍໃຊ້ MGD CLI: ຕັ້ງຄ່າ healthbot DeviceName outbound-ssh ປິດການໃຊ້ງານເປັນຄວາມຈິງ
• ທ່ານບໍ່ສາມາດດາວໂຫຼດບັນທຶກການບໍລິການທັງໝົດຈາກ 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, ການເຮັດວຽກຂອງສີຈະບໍ່ເຮັດວຽກ.
  ບັນຫານີ້ເກີດຂື້ນຖ້າ router ເຮັດວຽກຢູ່ໃນ Junos OS Release 20.1R1.
  ການແກ້ໄຂບັນຫາ: ອັບເກຣດ Junos OS ເປັນລຸ້ນ 21.4R1.
• Microservices ລົ້ມເຫລວໃນການເຊື່ອມຕໍ່ກັບ PostgresSQL ເນື່ອງຈາກ PostgresSQL ບໍ່ຍອມຮັບການເຊື່ອມຕໍ່ໃດໆໃນລະຫວ່າງການປ່ຽນບົດບາດຕົ້ນຕໍ. ນີ້ແມ່ນສະຖານະຊົ່ວຄາວ.
  Workaround: ໃຫ້ແນ່ໃຈວ່າ microservices ເຊື່ອມຕໍ່ກັບ PostgresSQL ຫຼັງຈາກການປ່ຽນແປງພາລະບົດບາດຕົ້ນຕໍສໍາເລັດ.
  •ຖານຂໍ້ມູນ Postgres ກາຍເປັນບໍ່ປະຕິບັດງານໃນບາງລະບົບ, ເຊິ່ງນໍາໄປສູ່ຄວາມລົ້ມເຫຼວຂອງການເຊື່ອມຕໍ່.
  ການແກ້ໄຂບັນຫາ: ປະຕິບັດຄໍາສັ່ງຕໍ່ໄປນີ້ໃນ node ຕົ້ນຕໍ: ສໍາລັບ pod ໃນ 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 server-limit rate-limit 600
• ຖ້າທ່ານໃຊ້ BGP-LS ເພື່ອໃຫ້ໄດ້ຂໍ້ມູນກ່ຽວກັບຄວາມລ່າຊ້າຂອງການເຊື່ອມຕໍ່ແລະການປ່ຽນແປງການຊັກຊ້າຂອງການເຊື່ອມຕໍ່, ທ່ານບໍ່ສາມາດ view ຂໍ້ມູນການຊັກຊ້າຂອງການເຊື່ອມຕໍ່ປະຫວັດສາດ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ໃນສະຖານະການທີ່ຫາຍາກ (ຕົວຢ່າງample, ເມື່ອ Redis ຂັດຂ້ອງແລະຖືກເປີດຄືນໃຫມ່ໂດຍອັດຕະໂນມັດໂດຍ Kubernetes, ຫຼືທ່ານຕ້ອງ restart ເຊີບເວີ Redis), ບາງຂໍ້ມູນການໂຕ້ຕອບຈະສູນເສຍແລະການໂຕ້ຕອບບໍ່ໄດ້ສະແດງຢູ່ໃນແຖບການໂຕ້ຕອບຂອງຕາຕະລາງຂໍ້ມູນເຄືອຂ່າຍ. ແນວໃດກໍ່ຕາມ, ບັນຫານີ້ບໍ່ມີຜົນກະທົບຕໍ່ການຄິດໄລ່ເສັ້ນທາງ, ສະຖິຕິ, ຫຼືການຈັດຫາ LSP.
  ການແກ້ໄຂບັນຫາ: ເພື່ອຟື້ນຟູສ່ວນຕິດຕໍ່ໃນຕົວແບບເຄືອຂ່າຍສົດ, ໃຫ້ເຮັດວຽກການລວບລວມອຸປະກອນຄືນໃໝ່.
• ໃນແຖບ Tasks ຂອງ Add New Workflow ແລະແກ້ໄຂໜ້າ Workflow:
• ເຖິງແມ່ນວ່າທ່ານຄລິກໃສ່ທາງເລືອກຍົກເລີກ, ການປ່ຽນແປງທີ່ທ່ານໄດ້ເຮັດໃນຂະນະທີ່ການແກ້ໄຂວຽກງານຈະຖືກບັນທຶກໄວ້.
• ທ່ານ​ບໍ່​ສາ​ມາດ​ນໍາ​ໃຊ້​ຊື່​ຂອງ​ຂັ້ນ​ຕອນ​ທີ່​ທ່ານ​ໄດ້​ລຶບ​ໄປ​ແລ້ວ​.
• ຂໍ້​ຄວາມ​ຜິດ​ພາດ​ຈະ​ບໍ່​ໄດ້​ຮັບ​ການ​ສະ​ແດງ​ເຖິງ​ແມ່ນ​ວ່າ​ໃນ​ເວ​ລາ​ທີ່​ທ່ານ​ເພີ່ມ​ຂັ້ນ​ຕອນ​ທີ່​ມີ​ລາຍ​ການ​ເປົ່າ​ແລະ​ຄລິກ​ໃສ່​ບັນ​ທຶກ​ແລະ​ການ​ນໍາ​ໃຊ້​.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ອັບເກຣດອຸປະກອນ PTX ລະດັບຕ່ຳບາງອັນດ້ວຍໂໝດ RE Dual (ຕົວຢ່າງample, PTX5000 ແລະ PTX300) ບໍ່ຮອງຮັບໃນ Paragon Automation. ນີ້ແມ່ນຍ້ອນວ່າອຸປະກອນ PTX ຕ່ໍາສຸດທີ່ມີໂຫມດ RE Dual ບໍ່ສະຫນັບສະຫນູນການຕັ້ງຄ່າໂດເມນຂົວຫຼືຂົວ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• 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 ດ້ວຍວິທີການ routing ເປັນ routeByDevice, ທ່ານຕ້ອງລະບຸຄ່າສໍາລັບ segment routing-Explicit Route object (SR-ERO); ຖ້າບໍ່ດັ່ງນັ້ນ, ທ່ານບໍ່ສາມາດໃຊ້ SRv6 LSP ເພື່ອປະຕິບັດການຈະລາຈອນ.
  ການແກ້ໄຂບັນຫາ: ໃນຂະນະທີ່ເພີ່ມອຸໂມງ, ໃນແຖບເສັ້ນທາງ, ເພີ່ມ hops ເພື່ອລະບຸປະເພດເສັ້ນທາງທີ່ຕ້ອງການຫຼືຕ້ອງການ.
• ຖ້າ SRv6 LSP ຄວບຄຸມອຸປະກອນຖືກຄົ້ນພົບຈາກເຄືອຂ່າຍ, ເສັ້ນທາງທີ່ເນັ້ນໃສ່ສໍາລັບ LSP ນີ້ຈະບໍ່ຖືກຕ້ອງໂດຍບໍ່ຄໍານຶງເຖິງວ່າທ່ານຈະລະບຸວັດຖຸ Explicit Route (ERO) ສໍາລັບເສັ້ນທາງຫຼືບໍ່.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ບາງຄັ້ງ, ທ່ານອາດຈະບໍ່ສາມາດລຶບ segment routing LSPs ເປັນຊຸດໄດ້.
  ການແກ້ໄຂບັນຫາ: ທ່ານສາມາດບັງຄັບໃຫ້ລຶບ LSPs ທີ່ບໍ່ຖືກລຶບອອກໃນລະຫວ່າງຂະບວນການລຶບຈໍານວນຫລາຍ.
•  ໃນ Paragon Automation GUI, ໃນແຖບ Tasks ຂອງໜ້າ Add New Workflow ແລະ Edit Workflow, ຂໍ້ຄວາມສະແດງຂໍ້ຜິດພາດຕໍ່ໄປນີ້ຈະສະແດງຂຶ້ນເມື່ອທ່ານພະຍາຍາມແກ້ໄຂ ແລະບັນທຶກຂັ້ນຕອນທີ່ມີຢູ່ແລ້ວໂດຍບໍ່ມີການປ່ຽນແປງໃດໆ:
  ຊື່ມີຢູ່ແລ້ວ
  ການແກ້ໄຂບັນຫາ: ຖ້າເຈົ້າໄດ້ຄລິກຕົວເລືອກແກ້ໄຂຢ່າງຜິດພາດ, ໃຫ້ແນ່ໃຈວ່າຢ່າງໜ້ອຍເຈົ້າປ່ຽນຊື່ຂອງຂັ້ນຕອນ.
• ບາງຄັ້ງກອງປະຊຸມ PCEP ຈະຖືກສະແດງເປັນ Down ຖ້າທ່ານ restart pods ທັງຫມົດໃນ namespace ເຫນືອ.
  ການແກ້ໄຂບັນຫາ: ຣີສະຕາດເຊີບເວີ topology ໂດຍໃຊ້ kubectl delete pods ns-toposerver- -n ຄໍາ​ສັ່ງ​ດາວ​ເຫນືອ​.
• ໃນໜ້າບໍລິຫານ> ການຈັດການໃບອະນຸຍາດ, ທ່ານບໍ່ສາມາດ view ຊື່ SKU ຂອງໃບອະນຸຍາດ ເມື່ອທ່ານເລືອກໃບອະນຸຍາດ ແລະຈາກນັ້ນເລືອກ ເພີ່ມເຕີມ > ລາຍລະອຽດ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ເສັ້ນສະແດງໃນໜ້າໂມງປຸກບໍ່ສະທ້ອນຂໍ້ມູນຫຼ້າສຸດ. ນັ້ນແມ່ນ, ກຣາບບໍ່ໄດ້ຖືກປັບປຸງຫຼັງຈາກສັນຍານເຕືອນບໍ່ໄດ້ເຮັດວຽກອີກຕໍ່ໄປ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ໃນເວລາທີ່ທ່ານ configure SSH ຂາອອກສໍາລັບ iAgent, ຂໍ້ມູນສໍາລັບກົດລະບຽບ configured ຈະບໍ່ຖືກສ້າງຂຶ້ນ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ຄ່າສູນຮ້ອຍເປີເຊັນຂອງການສູນເສຍແພັກເກັດຈະສະແດງລະຫວ່າງການເຊື່ອມຕໍ່ຖ້າທ່ານໄດ້ປັບຄ່າ 2-Way Active Management Protocol (TW)AMP). ນີ້ແມ່ນບໍ່ຖືກຕ້ອງເພາະວ່າ TWAMP ບໍ່ສະຫນັບສະຫນູນການສົ່ງອອກການສູນເສຍແພັກເກັດສໍາລັບວິສະວະກໍາການຈະລາຈອນ IS-IS.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ຖ້າທ່ານກໍາລັງໃຊ້ອຸປະກອນທີ່ມີບັດສາຍ MPC10+ ແລະຖ້າອຸປະກອນກໍາລັງເຮັດວຽກຢູ່ໃນ Junos OS Release ອື່ນທີ່ບໍ່ແມ່ນ Release 21.3R2-S2 ຫຼື Release 21.4R2-S1, ຫຼັງຈາກນັ້ນ, ສະຖິຕິສໍາລັບການໂຕ້ຕອບຢ່າງມີເຫດຜົນບໍ່ໄດ້ຖືກເກັບກໍາ. ຢ່າງໃດກໍ່ຕາມ, ສະຖິຕິສໍາລັບການໂຕ້ຕອບທາງດ້ານຮ່າງກາຍແລະ LSPs ແມ່ນເກັບກໍາ.
  ການແກ້ໄຂບັນຫາ: ອັບເກຣດລຸ້ນ Junos OS ໄປເປັນລຸ້ນ 21.3R2-S2 ຫຼື 21.4R2-S1. ນອກຈາກນີ້, ໃຫ້ແນ່ໃຈວ່າທ່ານໄດ້ອັບເກຣດ Paragon Automation ເປັນ Release 23.1.
• ເມື່ອທ່ານຍົກເລີກການມອບໝາຍ LSP, ສະຖານະ LSP ຈະຖືກສະແດງວ່າເປັນການມອບໝາຍ. ເມື່ອທ່ານພະຍາຍາມຍົກເລີກການແຕ່ງຕັ້ງ LSP ອີກຄັ້ງ, ການຕັ້ງຄ່າເຣົາເຕີອາດຈະຖືກແກ້ໄຂເພື່ອເພີ່ມວັດຖຸເສັ້ນທາງທີ່ຊັດເຈນ (ERO).
  ການແກ້ໄຂບັນຫາ: ໂຫຼດແຖບ Tunnel ຄືນໃໝ່ກ່ອນທີ່ທ່ານຈະຍົກເລີກການມອບໝາຍ LSP ອີກຄັ້ງ.
• Paragon Pathfinder ບໍ່ໄດ້ນໍາເອົາ SR LSP ທີ່ຖືກມອບຫມາຍລົງເມື່ອ SR LSP ບໍ່ຕອບສະຫນອງຂໍ້ຈໍາກັດຂອງຊິ້ນຖ້າສະຖານະພາບຂອງ SR LSP ຖືກສົ່ງກັບທ້ອງຖິ່ນ.
• ຖ້າ​ຫາກ​ທ່ານ​ສ້າງ​ກຸ່ມ topology ທີ່​ມີ Slice ID ຫຼາຍ​ກວ່າ​ຫຼື​ເທົ່າ​ທຽມ​ກັບ 2**32, ກຸ່ມ topology ID ຈະ​ບໍ່​ກົງ​ກັບ Slice ID.
• ກຸ່ມ Paragon Automation Kubernetes ໃຊ້ໃບຮັບຮອງ kubeadm ທີ່ສ້າງຂຶ້ນເອງ.
  ໃບຢັ້ງຢືນເຫຼົ່ານີ້ຈະໝົດອາຍຸໃນໜຶ່ງປີຫຼັງຈາກການນຳໃຊ້ ເວັ້ນເສຍແຕ່ວ່າສະບັບ Kubernetes ຈະຖືກອັບເກຣດ ຫຼື ມີການຕໍ່ອາຍຸໃບຢັ້ງຢືນດ້ວຍຕົນເອງ. ຖ້າໃບຮັບຮອງໝົດອາຍຸ, ຝັກບໍ່ມາ ແລະສະແດງຂໍ້ຜິດພາດຂອງໃບຮັບຮອງທີ່ບໍ່ດີຢູ່ໃນບັນທຶກ.
  ການແກ້ໄຂບັນຫາ: ຕໍ່ອາຍຸໃບຢັ້ງຢືນດ້ວຍຕົນເອງ. ປະຕິບັດຕາມຂັ້ນຕອນຕໍ່ໄປນີ້ເພື່ອຕໍ່ອາຍຸໃບຢັ້ງຢືນ:

1. ກວດເບິ່ງວັນໝົດອາຍຸຂອງໃບຢັ້ງຢືນໃນປະຈຸບັນໂດຍການໃຊ້ຄຳສັ່ງ kubeadm certs check-expiration ຢູ່ໃນແຕ່ລະ node ຫຼັກຂອງ cluster ຂອງທ່ານ.
2. ເພື່ອຕໍ່ອາຍຸໃບຢັ້ງຢືນ, ໃຫ້ໃຊ້ certs kubeadm ຕໍ່ອາຍຸຄໍາສັ່ງທັງໝົດຢູ່ໃນແຕ່ລະ node ຫຼັກຂອງກຸ່ມ Kubernetes ຂອງທ່ານ.
3. ກວດເບິ່ງວັນໝົດອາຍຸຄືນໃໝ່ໂດຍໃຊ້ຄຳສັ່ງ kubeadm certs check-expiration ໃນແຕ່ລະ node ຫຼັກຂອງ cluster ຂອງທ່ານ.
4. ຣີສະຕາດພອດຕໍ່ໄປນີ້ຈາກໜຶ່ງໃນໂນດຫຼັກເພື່ອໃຊ້ໃບຮັບຮອງໃໝ່.

ບັນຫາທີ່ແກ້ໄຂແລ້ວ

ພາກນີ້ສະແດງບັນຫາທີ່ແກ້ໄຂໄດ້ໃນ Juniper Paragon Automation Release 24.1

• LSPs ຄູ່ Symmetrically ອາດຈະບໍ່ຖືກສົ່ງຕາມຄວາມສົມມາຕຖານຕາມການປ່ຽນເສັ້ນທາງຂ້າມຂອບເຂດ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ຕາຕະລາງການຈາລະຈອນໄດ້ຮັບການສະຫນັບສະຫນູນໃນປັດຈຸບັນສໍາລັບອຸປະກອນທີ່ມີເຄື່ອງຈັກ Routing ຄູ່ທີ່ຂຶ້ນກັບ re0 ຫຼື re1 ຕໍ່ຊື່ເຈົ້າພາບຂອງພວກເຂົາ. ແນວໃດກໍ່ຕາມ, ກຣາຟແມ່ນຮອງຮັບພຽງແຕ່ຖ້າ hostname-suffixes ຢູ່ໃນຕົວນ້ອຍ ແລະໃນຮູບແບບ -re0 ຫຼື -re1. ຕົວຢ່າງample: vmx101-re0 ຫຼື vmx101-re1
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ
• ສະຖານທີ່ຄວບຄຸມບໍ່ໄດ້ລວມຢູ່ໃນແຟ້ມຈັດເກັບເຄືອຂ່າຍສໍາລັບ Paragon Planner.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ສະ​ຖາ​ນະ​ພາບ Safe Mode ແມ່ນ​ເປັນ​ຜິດ​ສະ​ເຫມີ​ໄປ​ເມື່ອ ns-web ຝັກເລີ່ມຕົ້ນ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ທ່ານໄດ້ຮັບສະຖານະຂອງ Safe Mode ທີ່ບໍ່ຖືກຕ້ອງຫຼັງຈາກທີ່ທ່ານແກ້ໄຂທຸງແຫຼ່ງຄວາມຈິງໃນລະຫວ່າງ Safe Mode.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ບາງຄັ້ງອຸປະກອນທີ່ປິດການໃຊ້ງານ NETCONF ປະກົດຂຶ້ນດ້ວຍສະຖານະ NETCONF.
  ການແກ້ໄຂບັນຫາ: ແກ້ໄຂອຸປະກອນເສີມfile ໂດຍ​ບໍ່​ມີ​ການ​ປ່ຽນ​ແປງ​ທີ່​ຈະ​ກະ​ຕຸ້ນ​ໃຫ້​ມີ​ການ​ໂຫຼດ​ໃຫມ່​ຂອງ​ອຸ​ປະ​ກອນ pro​file.
• ສີສໍາລັບ SR-TE LSPs ທີ່ມາຈາກອຸປະກອນ Cisco IOS-XR ແມ່ນເຫັນໄດ້ພຽງແຕ່ຖ້າ LSP ຖືກຄົ້ນພົບໃນເບື້ອງຕົ້ນຈາກການລວບລວມອຸປະກອນ.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ກຸ່ມຜູ້ເບິ່ງແຍງລະບົບຂອງ SR-TE LSP ທີ່ຮຽນຮູ້ຈາກ PCEP ຫາຍໄປຫຼັງຈາກ synchronization topology, ຖ້າ LSP ໄດ້ຕັ້ງຄ່າສະຖານະ.
  ການແກ້ໄຂ: ແກ້ໄຂ SR-TE LSP ເພື່ອສືບຕໍ່ກຸ່ມຜູ້ບໍລິຫານທີ່ໄດ້ຮຽນຮູ້ຈາກ PCEP.
• LSPs ໃນເສັ້ນທາງທີ່ດີທີ່ສຸດອາດຈະໄດ້ຮັບການປັບປຸງ PCEP ທີ່ບໍ່ຈໍາເປັນໃນລະຫວ່າງການເພີ່ມປະສິດທິພາບ PCS.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ຄວາມ​ຜິດ​ພາດ​ໃນ​ການ​ວິ​ເຄາະ​ຄຸນ​ສົມ​ບັດ (ການ​ຕັ້ງ​ຄ່າ​> ການ​ເຂົ້າ​ຂໍ້​ມູນ​> ການ​ວິ​ນິດ​ໄສ​> ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​) ເຮັດ​ໃຫ້​ການ​ທົດ​ສອບ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ບໍ່​ສໍາ​ເລັດ​.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ຢູ່ໃນແຖບ Network > Topology > Tunnel, ເມື່ອທ່ານເລື່ອນໃສ່ໄອຄອນ Filter (funnel) ແລະເລືອກ Add Filter, ຫນ້າ Add Criteria ຈະສະແດງຂຶ້ນ. ຖ້າ​ຫາກ​ທ່ານ​ເລືອກ​ເອົາ​ສີ​ໃນ​ບັນ​ຊີ​ລາຍ​ການ​ພາກ​ສະ​ຫນາມ​, ຄ່າ​ພາກ​ສະ​ຫນາມ​ຈະ​ສະ​ແດງ​ເປັນ​ການ​ວາງ​ແຜນ​ຄຸນ​ສົມ​ບັດ​ແທນ​ທີ່​ຈະ​ເປັນ​ສີ​.
  ການແກ້ໄຂບັນຫາ: ບໍ່ມີ.
• ບົດລາຍງານການວິເຄາະເສັ້ນທາງຫວ່າງເປົ່າ.

ການແກ້ໄຂບັນຫາ: ດໍາເນີນການເກັບກໍາຂໍ້ມູນອຸປະກອນກ່ອນທີ່ຈະດໍາເນີນການວິເຄາະເສັ້ນທາງ. ໃຫ້ສັງເກດວ່າ, ບົດລາຍງານການວິເຄາະເສັ້ນທາງສາມາດຫວ່າງເປົ່າຖ້າ LSPs ຢູ່ໃນເສັ້ນທາງທີ່ດີທີ່ສຸດ.

Juniper Networks, ໂລໂກ້ Juniper Networks, Juniper, ແລະ Junos ແມ່ນເຄື່ອງໝາຍການຄ້າທີ່ຈົດທະບຽນຂອງ Juniper Networks, Inc. ໃນສະຫະລັດ ແລະປະເທດອື່ນໆ. ເຄື່ອງໝາຍການຄ້າອື່ນໆທັງໝົດ, ເຄື່ອງໝາຍການບໍລິການ, ເຄື່ອງໝາຍຈົດທະບຽນ ຫຼືເຄື່ອງໝາຍການບໍລິການທີ່ລົງທະບຽນແມ່ນເປັນຊັບສິນຂອງເຈົ້າຂອງຂອງເຂົາເຈົ້າ. Juniper Networks ຖືວ່າບໍ່ມີຄວາມຮັບຜິດຊອບຕໍ່ຄວາມບໍ່ຖືກຕ້ອງໃດໆໃນເອກະສານນີ້. Juniper Networks ສະຫງວນສິດໃນການປ່ຽນແປງ, ປັບປຸງແກ້ໄຂ, ໂອນ, ຫຼືແກ້ໄຂສິ່ງພິມນີ້ໂດຍບໍ່ມີການແຈ້ງລ່ວງໜ້າ. ສະຫງວນລິຂະສິດ © 2024 Juniper Networks, Inc. ສະຫງວນລິຂະສິດທັງໝົດ.

ເອກະສານ / ຊັບພະຍາກອນ

Juniper NETWORKS Paragon ຊອບແວອັດຕະໂນມັດ [pdf] ຄູ່ມືຜູ້ໃຊ້ ຊອບແວອັດຕະໂນມັດ Paragon, ຊອບແວອັດຕະໂນມັດ, ຊອບແວ

ເອກະສານອ້າງອີງ

• ຄູ່ມືຜູ້ໃຊ້