คู่มือผู้ใช้ขั้นต่ำสำหรับการอัพเกรด IP Fabric ของ Juniper NETWORKS

Juniper Networks, โลโก้ Juniper Networks, Juniper และ Junos เป็นเครื่องหมายการค้าจดทะเบียนของ Juniper Networks, Inc. ในสหรัฐอเมริกาและประเทศอื่นๆ เครื่องหมายการค้า เครื่องหมายบริการ เครื่องหมายจดทะเบียน หรือเครื่องหมายบริการจดทะเบียนอื่นๆ ทั้งหมดเป็นทรัพย์สินของเจ้าของที่เกี่ยวข้อง

Juniper Networks ไม่รับผิดชอบต่อความไม่ถูกต้องใดๆ ในเอกสารนี้ Juniper Networks ขอสงวนสิทธิ์ในการเปลี่ยนแปลง แก้ไข โอน หรือแก้ไขเอกสารนี้โดยไม่ต้องแจ้งให้ทราบ

ข้อมูลในเอกสารนี้เป็นข้อมูลปัจจุบัน ณ วันที่ในหน้าชื่อเรื่อง

ประกาศปี 2000
ผลิตภัณฑ์ฮาร์ดแวร์และซอฟต์แวร์ของ Juniper Networks เป็นไปตามมาตรฐานปี 2000 Junos OS ไม่มีข้อจำกัดเกี่ยวกับเวลาที่ทราบจนถึงปี 2038
อย่างไรก็ตาม เป็นที่ทราบกันว่าแอปพลิเคชัน NTP จะมีปัญหาในปี 2036

ข้อตกลงอนุญาตสิทธิ์การใช้งานสำหรับผู้ใช้ปลายทาง
ผลิตภัณฑ์ Juniper Networks ที่อยู่ภายใต้เอกสารทางเทคนิคนี้ประกอบด้วย (หรือมีไว้สำหรับใช้กับ) ซอฟต์แวร์ Juniper Networks
การใช้ซอฟต์แวร์ดังกล่าวอยู่ภายใต้ข้อกำหนดและเงื่อนไขของข้อตกลงสิทธิ์การใช้งานสำหรับผู้ใช้ปลายทาง (“EULA”) ซึ่งโพสต์ไว้ที่https://support.juniper.net/support/eula/. โดยการดาวน์โหลด ติดตั้ง หรือใช้ซอฟต์แวร์ดังกล่าว แสดงว่าคุณยอมรับข้อกำหนดและเงื่อนไขของ EULA นั้น

บทที่ 1 การอัพเกรด IP Fabric สิ้นสุดลงview

เกี่ยวกับการกำหนดค่านี้ เช่นample

เกินview
ใช้การกำหนดค่าเครือข่ายนี้ เช่นample (NCE) เพื่ออัปเกรดสวิตช์ทั้งหมดในสถาปัตยกรรม IP Fabric ที่เปิดใช้งานอยู่แล้ว
ข้อเสนอแนะเกี่ยวกับเอกสาร

เราขอแนะนำให้คุณแสดงความคิดเห็นเพื่อที่เราจะได้นำไปปรับปรุงเอกสารของเราได้
ส่งความเห็นของคุณมาที่ การออกแบบศูนย์ความคิดเห็น@juniper.net. รวมเอกสารหรือชื่อหัวข้อ URL หรือหมายเลขหน้า และเวอร์ชันของซอฟต์แวร์ (ถ้ามี)

บทที่ 2 วางแผนการอัพเกรดสวิตช์ในสถาปัตยกรรม IP Fabric

การวางแผนการอัพเกรด

ส่วนนี้ครอบคลุมถึงแนวทางในการวางแผนการอัพเกรด
อัปเกรดอุปกรณ์ทีละเครื่องในระยะเริ่มต้นเสมอ หลังจากอัปเกรดได้สำเร็จไม่กี่ครั้งและพัฒนาความคุ้นเคยกับขั้นตอนนี้ คุณสามารถอัปเกรดสวิตช์เป็นชุด โดยใช้สวิตช์ลีฟหลายตัวในแต่ละครั้ง เพื่อการปรับใช้ขนาดใหญ่ ขอแนะนำให้อัปเกรดสวิตช์สไปน์และซูเปอร์สไปน์ทีละรายการ เพื่อป้องกันการหยุดชะงักของการรับส่งข้อมูลในกรณีที่ไม่มีเส้นทางซ้ำซ้อน

ตรวจสอบการใช้แบนด์วิธปัจจุบันของลิงค์เครือข่ายทั้งหมด
สามารถใช้ขั้นตอนการอัพเกรดทั้งแบบ in-band และ out-of-band หากแม้แต่สวิตช์ตัวเดียวใน IP Fabric ก็ใช้การอัพเกรดตาม ZTP ผ่านขั้นตอนในแบนด์ รีเลย์ DHCP จำเป็นต้องได้รับการกำหนดค่าบนสวิตช์ทั้งหมดใน IP Fabric เพื่อให้แน่ใจว่าสวิตช์ที่กำลังอัปเกรดจะสามารถเข้าถึงเซิร์ฟเวอร์ DHCP ต่อไปเพื่อดาวน์โหลดอิมเมจซอฟต์แวร์และดาวน์โหลดการกำหนดค่าสวิตช์ หากสวิตช์ทั้งหมดใน IP Fabric ได้รับการอัปเกรดผ่าน ISSU/NSSU ก็ไม่จำเป็นต้องกำหนดค่ารีเลย์ DHCP บนสวิตช์ใดๆ ใน IP Fabric สำหรับขั้นตอนในแบนด์

มีคำสั่งการแสดง CLI บางคำสั่งที่ใช้และรวบรวมข้อมูล ขอแนะนำให้ใช้คำสั่ง CLI ในสคริปต์โดยอัตโนมัติและจัดเก็บข้อมูลทั้งหมดไว้บนเซิร์ฟเวอร์ ใช้เครื่องมือเพื่อค้นหาและเปรียบเทียบรายละเอียดกับข้อมูลที่รวบรวมได้อย่างรวดเร็ว
ระบุและออกแบบโฟลว์การรับส่งข้อมูลที่สามารถตรวจสอบการเชื่อมต่อเครือข่ายและสามารถทำงานในพื้นหลังระหว่างการอัพเกรด โดยทั่วไปจะใช้ Ping และ Traceroute เพื่อจุดประสงค์นี้

วางแผนเวลาให้เพียงพอสำหรับช่วงเวลาการบำรุงรักษา (MW) อาจต้องใช้ MW หลายตัวสำหรับการปรับใช้ขนาดใหญ่ อัปเกรดอุปกรณ์ทีละเครื่องในระยะเริ่มต้นเสมอ หลังจากอัปเกรดได้สำเร็จไม่กี่ครั้งและทำความคุ้นเคยกับขั้นตอนดังกล่าวแล้ว การอัพเกรดสามารถทำได้เป็นชุดโดยใช้ลีฟสวิตช์หลายตัวในแต่ละครั้งเพื่อการปรับใช้ขนาดใหญ่
กำหนดเวลาการเปลี่ยนแปลงกับทีมและบุคคลที่ได้รับผลกระทบจากการเปลี่ยนแปลงทั้งหมด

เอกสารนี้สนับสนุน multi-homing ของโฮสต์เซิร์ฟเวอร์ไปยัง top-of-rack (TOR) หรือ leaf switch ที่แตกต่างกันโดยใช้การเชื่อมต่อ LACP ที่ใช้ LACP

บทที่ 3 สถาปัตยกรรมการปรับใช้

DC IP Routed Fabric 5 สtage ปิดด้วย Super Spine

สถาปัตยกรรมนี้ประกอบด้วย DC IP Routed Fabric 5 Stage Clos ด้วย Super Spine โดยมี eBGP เป็นโปรโตคอลแฟบริคโดยทุกเลเยอร์ใน AS ที่แตกต่างกัน
รูปที่ 1: IP Fabric Topology พร้อมโปรโตคอล EBGP Fabric โดยทุกเลเยอร์ใน AS ที่แตกต่างกัน
ผ้าที่กำหนดเส้นทางด้วยสถาปัตยกรรม Super Spine
แพลตฟอร์มที่รองรับ
ตารางที่ 1 แสดงรายการแพลตฟอร์มที่รองรับสำหรับบทบาทที่แตกต่างกันใน IP Fabric
ตารางที่ 1: แพลตฟอร์มที่รองรับสำหรับ IP Fabric

บทบาทของอุปกรณ์	แพลตฟอร์ม
ลีฟ/ทอร์	QFX5130-32CD QFX5220-32CD /128C QFX5120-32C/48Y/48T/48YM QFX5100/QFX5110-48S QFX5200-32C QFX5210-64C ACX7100-48L
กระดูกสันหลัง	QFX5220-32CD/128C PTX10K8 /16

บทบาทของอุปกรณ์	แพลตฟอร์ม
	QFX5120-32C QFX5210-64C QFX5130-32CD QFX5700 QFX5200-32C PTX10003 QFX5110-32Q
ซุปเปอร์สไปน์	QFX5220-128C PTX10K8/PTX10K3 QFX5210-64C QFX10K8/16

บันทึก: ในแพลตฟอร์มที่รองรับตามรายการ PTX10K8/16, QFX5700, QFX10K8/16 เป็นระบบโมดูลาร์ที่ใช้แชสซี แพลตฟอร์มที่เหลือคือฟอร์มแฟคเตอร์คงที่ขนาด 1, 2 หรือ 3 ยูนิตชั้นวาง (RU)

บทบาทของโหนด
ในรูปที่ 1 ต่อไปนี้เป็นบทบาทของโหนด:

P1L1, P1L2, P1L3 และ P1L4 เป็นโหนดลีฟใน POD-1

P2L2, P2L2, P2L3 และ P2L4 เป็นโหนดลีฟใน POD-2
P1S1, P1S2, P1S3, P1S4 เป็นโหนดกระดูกสันหลังใน POD-1

P2S1, P2S2, P2S3, P2S4 เป็นโหนดกระดูกสันหลังใน POD-2
SS1, SS2, SS3, SS4 เป็นซุปเปอร์สไปน์ในชั้นซุปเปอร์สไปน์ ซึ่งพบได้ทั่วไปในทั้ง POD-1 และ POD-2

การกำหนดค่าสวิตช์

คาดว่า IP Fabric จะใช้การกำหนดค่าพื้นฐานขั้นต่ำที่จำเป็นเพื่อให้สามารถทำงานได้ ดู รูปภาพ 1 ต่อไปนี้เป็นคำอธิบายขั้นต่ำของข้อกำหนดในการกำหนดค่า:

Fabric ได้รับการกำหนดค่าสำหรับ Dual Stack ที่มีทั้งการกำหนดเส้นทาง IPv4 และ IPv6 ใน Fabric
ลิงก์ทั้งหมดในแฟบริคเป็นแบบ P2P และกำหนดค่าสำหรับทั้ง IPv4 และ IPv6
eBGP ถูกใช้เป็นโปรโตคอลการกำหนดเส้นทาง
มีการใช้กลุ่มเพียร์ eBGP สวิตช์ลีฟทั้งหมดอยู่ในกลุ่มเพียร์ eBGP 1 กลุ่ม (เช่น LEAF) สวิตช์สไปน์ทั้งหมดอยู่ในกลุ่มเพียร์ eBGP 1 กลุ่ม (เช่น SPINE) และสวิตช์ super-spine ทั้งหมดเป็นของกลุ่มเพียร์ eBGP 1 กลุ่ม (พูด ซุปเปอร์สไปน์)
เส้นทางอาจถูกรวบรวมก่อนที่จะโฆษณาผ่าน eBGP
การรับส่งข้อมูลแบบสองทิศทางจะไหลผ่านสวิตช์ทั้งหมดในแฟบริค IP

บทที่ 4 อัปเกรดด้วยตนเองสำหรับสวิตช์ที่ไม่มี Juniper Apstra

แนวทางปฏิบัติสำหรับการอัปเกรดทีละชั้น
ในแต่ละเลเยอร์ ให้ระบุแพลตฟอร์มที่ใช้กันทั่วไปทั้งหมด เพื่อให้สามารถระบุข้อยกเว้นที่เกี่ยวข้องกับการอัปเกรดสำหรับแพลตฟอร์มอื่นๆ ได้

ขั้นตอนแรก – อัปเกรด TOR (Edge Switches)
อัปเกรด TOR ทั้งหมดทีละรายการ สันนิษฐานว่า TOR ทั้งหมดเป็นอุปกรณ์ RE เดียว ดังนั้น TOR ที่กำลังอัปเกรดจึงไม่พร้อมใช้งานในระหว่างการอัปเกรดสำหรับการส่งต่อเส้นทางข้อมูล ในกรณีที่เซิร์ฟเวอร์เชื่อมต่อกับ TOR เดียวที่กำลังอัปเกรด ให้ย้าย VM ไปยังเซิร์ฟเวอร์ที่เชื่อมต่อกับ TOR ที่ไม่ได้รับการอัปเกรด

ขั้นตอนที่สอง - อัปเกรดอุปกรณ์ Leaf
อัปเกรดสวิตช์ลีฟทั้งหมดทีละตัว: leaf1, leaf2, leaf3 และอื่นๆ สำหรับสวิตช์ RE คู่ ให้ใช้ขั้นตอน ISSU หรือ NSSU

ขั้นตอนที่สาม – อัปเกรดกระดูกสันหลัง
อัปเกรดสวิตช์กระดูกสันหลังทั้งหมดทีละตัว: กระดูกสันหลัง1, กระดูกสันหลัง2, กระดูกสันหลัง3 และอื่น ๆ สำหรับสวิตช์ RE คู่ ให้ใช้ขั้นตอน ISSU หรือ NSSU

ขั้นตอนที่สี่ - อัปเกรด Super-Spines
อัปเกรดสวิตช์ super-spine ทั้งหมดทีละตัว: super-spine1, super-spine2, super-spine3 และอื่นๆ สำหรับสวิตช์ RE คู่ ให้ใช้ขั้นตอน ISSU หรือ NSSU

ขั้นตอนทั่วไปสำหรับการอัพเกรดสวิตช์

การตรวจสุขภาพก่อนอัปเกรดและหลังอัปเกรด

เราขอแนะนำให้ตรวจสอบสภาพของสวิตช์ที่กำลังอัปเกรด ทั้งก่อนอัปเกรดและหลังอัปเกรด และบันทึกข้อมูลนี้ ข้อมูลการตรวจสอบสภาพก่อนอัปเกรดและหลังอัปเกรดที่บันทึกไว้สามารถเปรียบเทียบได้ในกรณีที่เกิดปัญหา

ขั้นตอนการตรวจสุขภาพ
ดำเนินการตามขั้นตอนต่อไปนี้:

ตรวจสอบว่าการรับส่งข้อมูลของผู้ใช้เป็นไปตามที่คาดไว้ โดยไม่มีการสูญเสียใดๆ ก่อนและหลังการอัปเกรด

สำรองข้อมูลการกำหนดค่าของอุปกรณ์ทั้งหมดและบันทึกไว้บนเซิร์ฟเวอร์ก่อนอัปเกรด
รวบรวมข้อมูลโดยละเอียดและตรวจสอบว่าระบบอยู่ในสภาพสมบูรณ์ทั้งก่อนและหลังการอัพเกรด
- ตรวจสอบ syslog เพื่อดูความล้มเหลวและข้อผิดพลาด
- แสดงข้อความบันทึก | ไม่มีอีกแล้ว
- แสดงบันทึกที่แชสซี | ไม่มีอีกแล้ว
- ตรวจสอบสัญญาณเตือนและ core-dump บนระบบ
  แสดงสัญญาณเตือนแชสซี | ไม่มีอีกแล้ว
  แสดงการเตือนของระบบ | ไม่มีอีกแล้ว
  แสดง core-dumps ของระบบ | ไม่มีอีกแล้ว
- ตรวจสอบสถานะ RE/FPC/PIC และสถานะอินเทอร์เฟซ (สำหรับแพลตฟอร์มทั้งหมดที่รองรับ)
  แสดงรายละเอียดฮาร์ดแวร์แชสซี | ไม่มีอีกแล้ว
  แสดงรายละเอียดแชสซี fpc | ไม่มีอีกแล้ว
  แสดงสถานะรูปแชสซี fpc | ไม่มีอีกแล้ว
  แสดงสภาพแวดล้อมแชสซี | ไม่มีอีกแล้ว
  แสดงเครื่องยนต์กำหนดเส้นทางแชสซี | ไม่มีอีกแล้ว
  แสดงคำอธิบายอินเทอร์เฟซ | จับคู่ | ไม่มีอีกแล้ว
  แสดงคำอธิบายอินเทอร์เฟซ | จับคู่ลง | ไม่มีอีกแล้ว
  แสดงอินเทอร์เฟซ xe-* | จับคู่ “ฟิสิคัล|อัตรา” | ไม่มีอีกแล้ว
  แสดงอินเทอร์เฟซ et-* | จับคู่ “ฟิสิคัล|อัตรา” | ไม่มีอีกแล้ว
  บนแพลตฟอร์มโมดูลาร์ที่ใช้แชสซี คุณยังสามารถรัน CLI ที่เกี่ยวข้องกับแฟบริคได้:
  แสดงสรุปผ้าแชสซี | ไม่มีอีกแล้ว
  แสดงผ้าแชสซี fpcs | ไม่มีอีกแล้ว
  สำหรับสวิตช์ RE คู่ เราจำเป็นต้องตรวจสอบความพร้อมในการสลับสำหรับ ISSU/NSSU:
  a. ในกรณีของสวิตช์ RE คู่ RE สำรองควรพร้อมสำหรับ GRES
  b. ตรวจสอบ Master RE : สถานะพร้อม “Switchover Ready” โดยการรันคำสั่ง “request chassis routing-engine master switch check”
  c. เรียกใช้คำสั่ง "show system switchover" ใน Backup RE และตรวจสอบให้แน่ใจว่าอยู่ในสถานะพร้อม
- ตรวจสอบตารางเส้นทางและตารางการส่งต่อ ซึ่งควรเป็นไปตามที่คาดไว้:
  แสดงกระบวนการของระบบอย่างกว้างขวาง | ไม่มีอีกแล้ว
  แสดงคิว krt | ไม่มีอีกแล้ว
  แสดงสรุปเส้นทาง | ไม่มีอีกแล้ว
  แสดงสรุปตารางการส่งต่อเส้นทาง | ไม่มีอีกแล้ว
  แสดง arp ไม่แก้ไขเวลาหมดอายุ | ไม่มีอีกแล้ว
  ใน ARP CLI ข้างต้น no-resolve บ่งชี้ว่าเราไม่ต้องการค้นหา DNS สำหรับทุกรายการในตาราง ARP ดังนั้น หากไม่แก้ไข เราจะเห็นเฉพาะที่อยู่ IP ซึ่งอาจเร็วขึ้นเมื่อคุณมีรายการ ARP หลายรายการ
- ตรวจสอบและจัดเก็บข้อมูลโดยละเอียดของข้อมูลที่เกี่ยวข้องกับ IP Fabric (สำหรับแพลตฟอร์มที่รองรับทั้งหมด):
- แสดงสถิติ pfe การจราจร | ไม่มีอีกแล้ว
- แสดงหน่วยความจำเสมือนของระบบ | ไม่มีอีกแล้ว
- แสดงรายละเอียดหน่วยความจำงาน | ไม่มีอีกแล้ว
- แสดงหน่วยความจำระบบ | ไม่มีอีกแล้ว
- แสดงหน่วยความจำงาน | ไม่มีอีกแล้ว
- แสดงแชสซี fpc | ไม่มีอีกแล้ว
- แสดงเครื่องยนต์กำหนดเส้นทางแชสซี | ไม่มีอีกแล้ว
- แสดงกระบวนการของระบบอย่างกว้างขวาง | ไม่มีอีกแล้ว
- แสดงรายละเอียดหน่วยความจำกระบวนการของระบบ | ไม่มีอีกแล้ว
- แสดงสรุป bgp | ไม่มีอีกแล้ว
- แสดงอินเทอร์เฟซ ae* terse | ไม่มีอีกแล้ว
- แสดงอินเทอร์เฟซ lacp
- แสดงอินเทอร์เฟซสถิติ lacp
- แสดงอินเทอร์เฟซสั้น | ไม่มาก
- แสดงเซสชั่น bfd | ไม่มีอีกแล้ว
  บนแพลตฟอร์มโมดูลาร์ที่ใช้แชสซี คุณสามารถเรียกใช้คำสั่งที่เกี่ยวข้องกับ Switch Interface Board (SIB) ได้:
  แสดงพี่น้องแชสซี | ไม่มีอีกแล้ว
  ดำเนินการตรวจสอบที่กำหนดเองและขั้นตอนการเตรียมการสำหรับอุปกรณ์อัปเกรดที่วางแผนไว้ หลังจากเสร็จสิ้นการตรวจสุขภาพ การตรวจสอบเหล่านี้จะต้องดำเนินการก่อนที่จะถึงขั้นตอนการอัพเกรดตามรายการในส่วนต่อไปนี้ของเอกสารนี้

การเตรียมตัวสำหรับการอัพเกรด

ดำเนินการตามขั้นตอนต่อไปนี้:

ตรวจสอบพื้นที่เก็บข้อมูลว่างของระบบเพื่อให้แน่ใจว่ามีพื้นที่เก็บข้อมูลเพียงพอสำหรับอิมเมจ Junos OS ใหม่:
- เรียกใช้ “df -k /var/tmp” ที่โหมดเชลล์เพื่อตรวจสอบพื้นที่ว่าง
- ในกรณีที่พื้นที่ว่างน้อยกว่าพื้นที่ที่จำเป็นสำหรับการอัพเกรด เราสามารถเพิ่มพื้นที่ว่างได้โดยใช้คำสั่งที่แสดงอยู่ในขั้นตอนที่ 2 สำหรับ ZTP ไม่มีข้อกำหนดพื้นที่ว่างดังกล่าว
เรียกใช้ "ร้องขอการล้างข้อมูลระบบจัดเก็บข้อมูลแบบแห้ง" ถัดจากตรวจสอบรายการที่เสนอ fileสำหรับการลบ:

ใช้คำสั่ง "ร้องขอการล้างที่เก็บข้อมูลระบบ" เพื่อเพิ่มพื้นที่เก็บข้อมูลบนอุปกรณ์หากรายการที่เสนอ fileที่จะลบก็เป็นที่ยอมรับ 3. ล้างการเตือนและ
- core-dumps ก่อนการอัพเกรด: o ล้างข้อผิดพลาดของระบบ fpc all fpc-slot 4
คัดลอกอิมเมจ Junos OS ไปยังไดเร็กทอรีอุปกรณ์ /var/tmp ใช้ขั้นตอนนี้เฉพาะในกรณีที่ไม่ได้ใช้ phone-home หรือ ZTP

อัปเกรดการดำเนินการเฉพาะ BGP บนกระดูกสันหลังล่วงหน้า
ดำเนินการตามขั้นตอนต่อไปนี้:

สันนิษฐานว่าสวิตช์แต่ละตัวที่กำลังอัปเกรดมีพารามิเตอร์ BGP ที่กำหนดค่าไว้ล่วงหน้าดังต่อไปนี้:
- ความล่าช้า-เส้นทาง-โฆษณา ขั้นต่ำ-ความล่าช้าขาเข้า-บรรจบกัน
- ความล่าช้า-เส้นทาง-โฆษณา ขั้นต่ำ-ความล่าช้าในการกำหนดเส้นทาง-เวลาทำงาน
  ทั้งนี้เพื่อให้แน่ใจว่าเส้นทาง BGP ได้รับการโฆษณาโดยสวิตช์หลังจากเปิดเครื่อง เฉพาะหลังจากที่มั่นใจในการบรรจบเส้นทางที่สวิตช์ในเครื่องเท่านั้น ซึ่งหมายความว่าเส้นทางใน RIB ได้รับการดาวน์โหลดไปยัง FIB ของสวิตช์แล้ว ในกรณีที่เส้นทางใน RIB ไม่พร้อมใช้งานที่ FIB เราเตอร์ในพื้นที่จะเริ่มโฆษณาเส้นทางทันทีหลังจากที่เส้นทางพร้อมใช้งานใน RIB แม้ว่า FIB จะไม่สามารถส่งต่อเส้นทางเหล่านั้นได้ อาจทำให้การรับส่งข้อมูลลดลงสำหรับปลายทางที่มีเส้นทางที่โฆษณาโดยเราเตอร์ท้องถิ่น แต่ไม่มีเส้นทางที่สอดคล้องกันใน FIB ของเราเตอร์ท้องถิ่น
  คำจำกัดความของพารามิเตอร์ BGP มีดังต่อไปนี้:
  การบรรจบกันขาเข้า - ระบุความล่าช้าขั้นต่ำในการโฆษณาเส้นทางหลังจากที่เพียร์ต้นทางได้ส่งการอัปเดตเส้นทางทั้งหมดไปยังเราเตอร์ท้องถิ่นที่กำลังอัปเกรด อุปกรณ์ภายในเครื่องที่กำลังอัปเกรดจะรออย่างน้อยตามระยะเวลาที่กำหนดไว้ หลังจากการบรรจบกันขาเข้าที่อุปกรณ์ภายในเครื่องเสร็จสิ้นสำหรับเพียร์ต้นทาง สำหรับเส้นทาง BGP เพียร์ต้นทางจะส่ง end-of-rib หลังจากส่งการอัปเดตเส้นทางทั้งหมดไปยังอุปกรณ์ในเครื่องแล้ว ค่าเริ่มต้นคือ 120 วินาที ช่วงคือ 1 ถึง 36000 วินาที
  หากเพียร์ BGP ทั้งหมดของอุปกรณ์เป็นประเภท IPv4 ให้รันคำสั่งต่อไปนี้:
- ตั้งค่าโปรโตคอล ตระกูล bgp การโฆษณาเส้นทางล่าช้าแบบ inet unicast ความล่าช้าขั้นต่ำในการบรรจบกันขาเข้า
  หากเพียร์ BGP ทั้งหมดของอุปกรณ์เป็นประเภท IPv6 ให้รันคำสั่งต่อไปนี้:
- ตั้งค่าโปรโตคอลตระกูล bgp inet6 unicast ล่าช้าเส้นทางโฆษณาความล่าช้าขั้นต่ำการบรรจบกันขาเข้า
  หากเพียร์ BGP ของอุปกรณ์บางตัวเป็นประเภท IPv4 และบางตัวเป็นประเภท IPv6 ดังนั้นการบรรจบกันขาเข้าบนอุปกรณ์ภายในจะต้องตั้งค่าแบบต่อเพียร์ สำหรับเพียร์ IPv4 BGP ให้รันคำสั่งต่อไปนี้:
- ตั้งค่าโปรโตคอลกลุ่ม bgp ตระกูลเพื่อนบ้าน inet unicast ความล่าช้าในเส้นทางโฆษณาความล่าช้าขั้นต่ำการบรรจบกันขาเข้า
  สำหรับเพียร์ IPv6 BGP ให้รันคำสั่งต่อไปนี้:
- ตั้งค่าโปรโตคอลกลุ่ม bgp ตระกูลเพื่อนบ้าน inet6 unicast ล่าช้าเส้นทางโฆษณาความล่าช้าขั้นต่ำการบรรจบกันขาเข้า
  b) เวลาทำงานขั้นต่ำในการกำหนดเส้นทาง – ระบุความล่าช้าขั้นต่ำในหน่วยวินาที ก่อนที่จะส่งโฆษณาเส้นทางหลังจากเริ่มกระบวนการโปรโตคอลการกำหนดเส้นทาง (rpd) อุปกรณ์จะรออย่างน้อยตามระยะเวลาที่กำหนดไว้ก่อนที่จะส่งโฆษณาเส้นทางไปยังเครื่องอื่น ค่าเริ่มต้นคือ 0 วินาที ช่วงคือ 1 ถึง 36000 วินาที
  หากเพียร์ BGP ทั้งหมดของอุปกรณ์เป็นประเภท IPv4 ให้รันคำสั่งต่อไปนี้:
- ตั้งค่าโปรโตคอลตระกูล bgp inet unicast ความล่าช้าในการกำหนดเส้นทางการโฆษณาเวลาขั้นต่ำในการกำหนดเส้นทางการหน่วงเวลาขั้นต่ำ
  หากเพียร์ BGP ทั้งหมดของอุปกรณ์เป็นประเภท IPv6 ให้รันคำสั่งต่อไปนี้:
- ตั้งค่าโปรโตคอลตระกูล bgp inet6 unicast ความล่าช้าในการกำหนดเส้นทางโฆษณาเวลาขั้นต่ำในการกำหนดเส้นทางการหน่วงเวลาขั้นต่ำ
  หากเพียร์ BGP ของอุปกรณ์บางตัวเป็นประเภท IPv4 และบางตัวเป็นประเภท IPv6 ดังนั้นเวลาทำงานของเส้นทางบนอุปกรณ์ภายในจะต้องตั้งค่าแบบต่อเพียร์ สำหรับเพียร์ IPv4 BGP ให้รันคำสั่งต่อไปนี้:
- ตั้งค่าโปรโตคอล กลุ่ม bgp ตระกูลเพื่อนบ้าน inet unicast ความล่าช้าในการกำหนดเส้นทางโฆษณา ความล่าช้าในการกำหนดเส้นทางขั้นต่ำขั้นต่ำ
  สำหรับเพียร์ IPv6 BGP ให้รันคำสั่งต่อไปนี้:
- ตั้งค่าโปรโตคอลกลุ่ม bgp ตระกูลเพื่อนบ้าน inet6 unicast ความล่าช้าในการกำหนดเส้นทางโฆษณาเวลาขั้นต่ำในการกำหนดเส้นทางการหน่วงเวลาขั้นต่ำ
  สำหรับข้อมูลเพิ่มเติม โปรดดู https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/ref/statement/ ล่าช้าเส้นทางโฆษณา-แก้ไขโปรโตคอล-group-family-unicast.html

หากเพียร์สวิตช์ BGP ส่งการรับส่งข้อมูลไปยังอุปกรณ์ ให้บันทึกสถิติการรับส่งข้อมูลขาออกที่เพิ่มขึ้น (แพ็กเก็ตเอาต์พุต) บนอินเทอร์เฟซที่เชื่อมต่ออุปกรณ์ของสวิตช์ ในกรณีที่มีอินเทอร์เฟซอีเทอร์เน็ตรวม ระหว่างสวิตช์เพียร์และอุปกรณ์ ให้ระบุอินเทอร์เฟซทางกายภาพที่เป็นส่วนประกอบโดยใช้คำสั่งต่อไปนี้บนสวิตช์เพียร์:
- แสดงอินเทอร์เฟซ lacp
  ตรวจสอบอัตราการรับส่งข้อมูลขาออกบนอินเทอร์เฟซทางกายภาพของสวิตช์เพียร์ ที่เชื่อมต่อกับอุปกรณ์ โดยใช้คำสั่งต่อไปนี้:
- แสดงอินเทอร์เฟซ <ชื่ออินเทอร์เฟซของสวิตช์เพียร์ที่เชื่อมต่อกับ DUT | อัตราเกรป
- ตรวจสอบการรับส่งข้อมูลอินเทอร์เฟซ
สร้างนโยบายสำหรับการปฏิเสธเส้นทาง:
- ตั้งค่าตัวเลือกนโยบาย นโยบายคำสั่ง แล้วปฏิเสธ

หากอุปกรณ์ได้รับการกำหนดค่าด้วย BGP ให้ถอนเส้นทาง BGP ที่โฆษณาไว้ทั้งหมดออกจากเพียร์ซุปเปอร์สไปน์ทั้งหมด ในที่นี้ กลุ่ม SUPER-SPINES หมายถึงสวิตช์ super-spine ทั้งหมดที่ทำหน้าที่เป็นเพื่อน BGP ของสวิตช์กระดูกสันหลังที่กำลังอัปเกรด:
- ตั้งค่าโปรโตคอลกลุ่ม bgp SUPER-SPINES ส่งออก DENY-ALL และคอมมิต สำหรับข้อมูลเกี่ยวกับคำสั่งส่งออกเส้นทาง BGP โปรดดู https://www.juniper.net/documentation/us/en/software/junos/bqp/topics/ref/statement/expor t-edit-protocols-bgp.html
หากอุปกรณ์ได้รับการกำหนดค่าด้วย BGP ให้ถอนเส้นทาง BGP ที่โฆษณาทั้งหมดออกจากเพียร์ลีฟทั้งหมด กลุ่ม LEAF ในที่นี้หมายถึงลีฟสวิตช์ที่ทำหน้าที่เป็นเพียร์ BGP ของสวิตช์สไปน์ที่กำลังอัปเกรด:
- ตั้งค่าโปรโตคอลกลุ่ม bgp LEAF ส่งออก DENY-ALL และคอมมิต
สังเกตที่อยู่ IP บนอุปกรณ์ที่ได้รับการกำหนดค่าบนอินเทอร์เฟซที่เชื่อมต่อสวิตช์เพียร์ BGP แต่ละตัว รันคำสั่งต่อไปนี้บนอุปกรณ์:
- แสดงอินเทอร์เฟซ โดยย่อ

ตรวจสอบบนสวิตช์เพียร์ BGP แต่ละตัว (ทั้ง super-spine และ leaf) ว่าเส้นทางที่ส่งออกโดยอุปกรณ์ถูกถอนออก:
- แสดงสรุป bap
  มีหลายรายการที่แสดง ตรวจสอบรายการที่เกี่ยวข้องกับอุปกรณ์ ซึ่งสามารถระบุได้โดยใช้ที่อยู่ IP ที่กำหนดค่าไว้บนอินเทอร์เฟซอุปกรณ์ที่เชื่อมต่อกับสวิตช์เพียร์ ซึ่งใช้ CLI นี้ ในรายการที่สอดคล้องกับอุปกรณ์ (บนสวิตช์เพียร์) เส้นทางที่ได้รับจากอุปกรณ์ควรแสดงเป็น 0/0/0/0 ใต้คอลัมน์
  สถานะ|#ใช้งานอยู่/ได้รับ/ยอมรับแล้ว/Dampบก.
- หรือคุณสามารถเรียกใช้คำสั่งต่อไปนี้บนสวิตช์เพียร์ BGP แต่ละตัว (ทั้ง super-spine และ leaf) ของอุปกรณ์:
- แสดง bgp เพื่อนบ้าน
  สิ่งนี้ควรแสดงข้อมูลเดียวกันภายใต้หัวข้อ:
  ตาราง inet.
หากสวิตช์เพียร์ BGP ใดๆ ส่งการรับส่งข้อมูลไปยังอุปกรณ์ ให้ตรวจสอบสถิติการรับส่งข้อมูลบนสวิตช์เพียร์นั้น และรอจนกระทั่งสถิติทางออกที่เพิ่มขึ้น (แพ็กเก็ตเอาท์พุต) บนอินเทอร์เฟซที่เชื่อมต่ออุปกรณ์นั้นเกือบจะเกือบ ในกรณีที่มีอินเทอร์เฟซอีเธอร์เน็ตรวมระหว่างสวิตช์เพียร์และอุปกรณ์นี้ ระบุอินเทอร์เฟซที่เป็นส่วนประกอบโดยใช้คำสั่งต่อไปนี้บนสวิตช์เพียร์:
- แสดงอินเทอร์เฟซ lacp ตรวจสอบอัตราการรับส่งข้อมูลขาออกบนอุปกรณ์ที่เชื่อมต่ออินเทอร์เฟซของสวิตช์เพียร์โดยใช้คำสั่งต่อไปนี้: แสดงอินเทอร์เฟซ <ชื่ออินเทอร์เฟซของสวิตช์เพียร์ที่เชื่อมต่อกับ DUT | อัตราเกรป
- ตรวจสอบการรับส่งข้อมูลอินเทอร์เฟซ

อัปเกรดการดำเนินการเฉพาะ BGP ล่วงหน้าบน Leaf
ดำเนินการตามขั้นตอนต่อไปนี้:

ทำตามขั้นตอนที่ 1 ของการดำเนินการเฉพาะ BGP ล่วงหน้าบนสวิตช์สไปน์

ขั้นตอนการถอนเส้นทาง BGP ที่โฆษณาบนลีฟสวิตช์ที่กำลังอัปเกรด จะคล้ายกับขั้นตอนของสไปน์สวิตช์มาก ถอนเส้นทางที่โฆษณาไปยังกระดูกสันหลังทั้งหมดที่ทำหน้าที่เป็นเพื่อน BGP:
- ตั้งค่าโปรโตคอลกลุ่ม bgp SPINES ส่งออก DENY-ALL และคอมมิต
  ในที่นี้ SPINES หมายถึงกลุ่มเพียร์ BGP ที่ได้รับการกำหนดค่าบนสวิตช์ลีฟสำหรับการเพียร์ด้วย
  กระดูกสันหลังทั้งหมดผ่าน BGP
ในกรณีที่สวิตช์ TOR (หรือโฮสต์เซิร์ฟเวอร์) เชื่อมต่อผ่าน L2 MC-LAG ไปยังสวิตช์ลีฟของอุปกรณ์ ให้ปิดใช้งานอินเทอร์เฟซทางกายภาพบนสวิตช์ลีฟที่เชื่อมต่อกับสวิตช์ TOR นั้น (หรือโฮสต์เซิร์ฟเวอร์) เนื่องจากสวิตช์ TOR (หรือโฮสต์เซิร์ฟเวอร์) อาจไม่ได้กำหนดค่า eBGP และทำงานตามการแฮช L2 ของการรับส่งข้อมูลทางเหนือไปยังสวิตช์ลีฟทั้งหมด
ดังนั้น ให้ปิดใช้งานอินเทอร์เฟซบนสวิตช์ลีฟของอุปกรณ์ที่กำลังอัปเกรด ไปทางสวิตช์ TOR (หรือโฮสต์เซิร์ฟเวอร์) วิธีนี้จะป้องกันไม่ให้สวิตช์ TOR (หรือโฮสต์เซิร์ฟเวอร์) ส่งการรับส่งข้อมูลไปยังสวิตช์ลีฟของอุปกรณ์ที่กำลังอัปเกรด o ตั้งค่าอินเทอร์เฟซปิดการใช้งานและคอมมิต

ทำตามขั้นตอนที่ 5 ถึง 7 ในกรณีที่ต้องอัปเกรดการดำเนินการ BGP บนกระดูกสันหลังล่วงหน้า

อัปเกรดการดำเนินการเฉพาะ BGP ล่วงหน้าบน Super-Spines
ดำเนินการตามขั้นตอนต่อไปนี้:

ทำตามขั้นตอนที่ 1 ของการดำเนินการเฉพาะ BGP ล่วงหน้าบนสวิตช์สไปน์

ขั้นตอนการถอนเส้นทาง BGP ที่โฆษณาบนสวิตช์ super-spine ที่กำลังอัปเกรด จะคล้ายกับขั้นตอนของ leaf switch ถอนเส้นทางที่โฆษณาไปยังกระดูกสันหลังทั้งหมดที่ทำหน้าที่เป็นเพื่อน BGP:
ตั้งค่าโปรโตคอลกลุ่ม bgp SPINES ส่งออก DENY-ALL และคอมมิต
ในที่นี้ SPINES หมายถึงกลุ่มเพียร์ BGP ที่ได้รับการกำหนดค่าบนสวิตช์ super-spine สำหรับการเพียร์กับหนามทั้งหมดผ่าน BGP ทำตามขั้นตอนที่ 5 ถึง 7 ในกรณีที่ต้องอัปเกรดการดำเนินการ BGP บนกระดูกสันหลังล่วงหน้า

อัปเกรดอุปกรณ์ด้วยอิมเมจใหม่และรีบูต
มีหลายวิธีในการอัพเกรดสวิตช์ด้วยอิมเมจใหม่:

การอัพเกรดตาม CLI
แซดทีพี
อีเอสยู

นสส
คำอธิบายโดยละเอียดมีอยู่ในส่วน รายละเอียดการอัปเกรดด้วยตนเองสำหรับสวิตช์ที่ไม่มี Juniper Apstra

กิจวัตรหลังการอัพเกรดทั่วไปสำหรับสวิตช์ RE เดี่ยวและ RE คู่ และบทบาทของสวิตช์ทั้งหมด

ดำเนินการตามขั้นตอนต่อไปนี้:
รอและตรวจสอบว่าอุปกรณ์พร้อมใช้งาน

ตรวจสอบว่าไม่มีแกนประมวลผล
- การดัมพ์ของระบบอย่างไร
ตรวจสอบว่าไม่มีสัญญาณเตือนระบบและแชสซีเพิ่มเติม
- แสดงสัญญาณเตือนแชสซี | ไม่มีอีกแล้ว
- แสดงการเตือนของระบบ | ไม่มีอีกแล้ว

การดำเนินการเฉพาะหลังการอัพเกรด BGP บนกระดูกสันหลัง
ดำเนินการตามขั้นตอนต่อไปนี้:

เริ่มเส้นทางการโฆษณาใหม่ไปยังเพียร์สไปน์ทั้งหมด ในที่นี้ กลุ่ม SUPER-SPINES หมายถึงสวิตช์ superspine ที่ทำหน้าที่เป็นเพื่อน BGP ของสวิตช์กระดูกสันหลังที่กำลังอัปเกรด:
- ลบโปรโตคอล กลุ่ม bgp SUPER-SPINES ส่งออก DENY-ALL และคอมมิต
เริ่มเส้นทางการโฆษณาใหม่ไปยังเพียร์ลีฟทั้งหมด ในที่นี้ กลุ่ม LEAF อ้างถึงสวิตช์ leaf ที่ทำหน้าที่เป็นเพียร์ BGP ของสวิตช์กระดูกสันหลังที่กำลังอัปเกรด: o ลบโปรโตคอล กลุ่ม bgp LEAF ส่งออก DENY-ALL และคอมมิต

ในกรณีที่การรับส่งข้อมูลถูกส่งจากสไปน์ใดๆ (ทำหน้าที่เป็นสวิตช์เพียร์ BGP) ไปยังอุปกรณ์ ให้ตรวจสอบสถิติการรับส่งข้อมูลบนสวิตช์เพียร์นั้น และรอจนกว่าสถิติทางออกที่เพิ่มขึ้น (แพ็กเก็ตเอาท์พุต) บนอินเทอร์เฟซที่เชื่อมต่อกับอุปกรณ์นั้นเกือบจะกลายเป็นค่าก่อนการอัปเกรด ในกรณีที่มีอินเทอร์เฟซอีเทอร์เน็ตแบบรวม ระหว่างสวิตช์เพียร์และอุปกรณ์ ให้ระบุอินเทอร์เฟซทางกายภาพที่เป็นส่วนประกอบโดยใช้ CLI นี้บนสวิตช์เพียร์:
- แสดงอินเทอร์เฟซ lacp
  ตรวจสอบอัตราการรับส่งข้อมูลขาออกบนอินเทอร์เฟซทางกายภาพของสวิตช์เพียร์ที่เชื่อมต่อกับสไปน์
- สวิตช์ที่กำลังอัปเกรดโดยใช้ CLI ต่อไปนี้: แสดงอินเทอร์เฟซ | อัตราเกรป
- ตรวจสอบการรับส่งข้อมูลอินเทอร์เฟซ

การดำเนินการเฉพาะหลังอัปเกรด BGP บน Leaf และ ToR Switch / โฮสต์เซิร์ฟเวอร์

ทำตามขั้นตอนต่อไปนี้: 1. เริ่มโฆษณาเส้นทาง BGP ใหม่บนสวิตช์ลีฟที่กำลังอัปเกรด ขั้นตอนนี้คล้ายกับการสลับกระดูกสันหลัง เริ่มเส้นทางการโฆษณาใหม่ไปยังสไปน์ทั้งหมดซึ่งทำหน้าที่เป็นเพียร์ BGP: o ลบโปรโตคอล กลุ่ม bgp SPINES ส่งออก DENY-ALL และคอมมิต ในที่นี้ SPINES หมายถึงกลุ่มเพียร์ BGP ที่ได้รับการกำหนดค่าบนสวิตช์ลีฟเพื่อการเพียร์กับหนามทั้งหมดผ่าน BGP

ในกรณีที่สวิตช์ TOR (หรือโฮสต์เซิร์ฟเวอร์) เชื่อมต่อกับสวิตช์ลีฟผ่าน L2 MC-LAG จะต้องเปิดใช้งานอินเทอร์เฟซทางกายภาพบนสวิตช์ลีฟที่เชื่อมต่อกับสวิตช์ TOR (หรือโฮสต์เซิร์ฟเวอร์) อีกครั้ง (หากปิดใช้งานก่อนหน้านี้ ). การดำเนินการนี้จะเปิดใช้งานสวิตช์ TOR (หรือโฮสต์เซิร์ฟเวอร์) อีกครั้งเพื่อส่งการรับส่งข้อมูลไปยังสวิตช์ลีฟทั้งหมด (รวมถึงสวิตช์ลีฟที่กำลังอัปเกรด) หลังจากการแฮช L2
- ตั้งค่าอินเทอร์เฟซให้เปิดใช้งานและคอมมิต
ทำตามขั้นตอนที่ 3 ในกรณีที่มีการดำเนินการ BGP บนกระดูกสันหลังหลังอัปเกรด

การดำเนินการเฉพาะหลังอัปเกรด BGP บน Super-Spines
ดำเนินการตามขั้นตอนต่อไปนี้:

เริ่มโฆษณาเส้นทาง BGP ใหม่บนสวิตช์ super-spine ที่กำลังอัปเกรด ขั้นตอนนี้คล้ายกับการสลับกระดูกสันหลัง เริ่มเส้นทางการโฆษณาอีกครั้งไปยังกระดูกสันหลังทั้งหมดที่ทำหน้าที่เป็นเพียร์ BGP:
- ลบโปรโตคอล กลุ่ม bgp SPINES ส่งออก DENY-ALL และคอมมิต
  ในที่นี้ SPINES หมายถึงกลุ่มเพียร์ BGP ที่ได้รับการกำหนดค่าบนสวิตช์ super-spine สำหรับ
  มองดูกระดูกสันหลังทั้งหมดผ่าน BGP ทำตามขั้นตอนที่ 3 ในกรณีที่มีการดำเนินการ BGP หลังอัปเกรด
  บนกระดูกสันหลัง

ทำตามขั้นตอนที่ 3 ในกรณีที่มีการดำเนินการ BGP บนกระดูกสันหลังหลังอัปเกรด

ตรวจสอบอินเทอร์เฟซ Core-Facing ของเครือข่ายทั้งหมด
ดำเนินการตามขั้นตอนต่อไปนี้:

รอและตรวจสอบการกำหนดเส้นทางด้านล่างทั้งหมดแล้ว

รอและตรวจสอบว่ามีการสร้างความสัมพันธ์เพื่อนบ้าน BGP แล้ว รอให้การอัปเดตเส้นทาง BGP เสร็จสิ้น
a) “แสดงสรุป bgp” และตรวจสอบสถานะที่จัดตั้งขึ้นสำหรับเพื่อนบ้านทั้งหมด
รอและตรวจสอบว่าอินเทอร์เฟซ IRB ใช้งานได้ สิ่งนี้ใช้ได้เฉพาะเมื่อมีการกำหนดค่าอินเทอร์เฟซ IRB ซึ่งมักจะเกิดขึ้นบนสวิตช์ ToR หรือ CE
a) แสดงอินเทอร์เฟซ irb

ตรวจสอบอินเทอร์เฟซการเข้าถึงแบบหันหน้าเข้าหาอุปกรณ์ปลายทางทั้งหมด
รอและตรวจสอบว่าการรับส่งข้อมูลของผู้ใช้ทั้งหมดกลับมาทำงานต่อตามปกติ

การตรวจสุขภาพหลังการอัพเกรด
ทำซ้ำขั้นตอนการตรวจสอบสภาพที่ดำเนินการก่อนการอัพเกรด ตามด้วยการตรวจสอบแบบกำหนดเองใดๆ

การล้างข้อมูลหลังการอัพเกรด

ลบอิมเมจที่ติดตั้งใหม่หากจำเป็น
คืนค่าการตั้งค่าการกำหนดค่า syslog กลับเป็นค่าดั้งเดิม

แพลตฟอร์มที่รองรับสำหรับขั้นตอนการอัพเกรดด้วยตนเอง (ไม่มี Juniper Apstra)

ตารางที่ 2 ให้รายละเอียดของแพลตฟอร์มที่รองรับ
ตารางที่ 2 ขั้นตอนการอัพเกรดด้วยตนเอง

วิธีการอัพเกรด	การอ้างอิงแพลตฟอร์มที่รองรับ
อีเอสยู	https://apps.juniper.net/feature-explorer/issu.html
นสส	https://apps.juniper.net/feature-explorer/feature- info.html?fKey=1175&fn=ไม่หยุด+ซอฟต์แวร์+อัปเกรด+%28NSSU%29
แซดทีพี	https://apps.juniper.net/feature-explorer/parent-feature- info.html?pFKey=1272&pFName=Zero+Touch+การจัดเตรียม

รายละเอียดการอัปเกรดด้วยตนเองสำหรับสวิตช์ที่ไม่มี Juniper Apstra

สวิตช์ RE ทั้งเดี่ยวและคู่
การอัพเกรดที่ใช้ CLI ปกติสามารถใช้ได้กับสวิตช์ RE เดี่ยวและคู่ นี่เป็นตัวเลือกการอัพเกรดที่ง่ายที่สุดและไม่มีคุณสมบัติที่ตัวเลือกอื่นรองรับ ขั้นแรก ftp แพ็คเกจซอฟต์แวร์ใหม่ไปยังไดเร็กทอรี /var/tmp บนอุปกรณ์ จากนั้นรันคำสั่งต่อไปนี้:
root@host> ร้องขอซอฟต์แวร์ระบบเพิ่ม รีบูต

สวิตช์ RE เดี่ยวเท่านั้น
Zero Touch Provisioning (ZTP) คืนค่าสวิตช์เป็นการกำหนดค่าเริ่มต้นจากโรงงาน ใน ZTP ต้องใช้การกำหนดค่าที่มีอยู่แล้วอีกครั้งผ่าน file เซิร์ฟเวอร์ที่เก็บอิมเมจ Junos OS Evolved หรือ Junos OS ไว้ เนื่องจากจะหายไป โปรดทราบว่าสวิตช์จะต้องอัปเกรดหลังจาก ZTP
เชื่อมต่อกับเซิร์ฟเวอร์การกำหนดค่า / เซิร์ฟเวอร์รูปภาพภายใต้ทุกสถานการณ์ เพื่อให้สามารถใช้การกำหนดค่าที่มีอยู่เดิมอีกครั้งได้หลังจาก ZTP สิ้นสุดลง

สมมติฐาน
อุปกรณ์ใช้ข้อมูลที่กำหนดค่าไว้บนเซิร์ฟเวอร์ Dynamic Host Configuration Protocol (DHCP) เพื่อค้นหาอิมเมจซอฟต์แวร์และการกำหนดค่าที่จำเป็น fileอยู่บนเครือข่าย หากเซิร์ฟเวอร์ DHCP ไม่ได้กำหนดค่าเพื่อให้ข้อมูลนี้ ซอฟต์แวร์ที่ติดตั้งไว้ล่วงหน้าและการกำหนดค่าเริ่มต้นจากโรงงานจะถูกโหลด

เอกสารนี้จะถือว่า dhcpd, vsftpd, tftpd และ httpd ได้รับการติดตั้งและกำหนดค่าให้รองรับ ZTP อุปกรณ์ที่เตรียมไว้สำหรับการดาวน์โหลดรูปภาพและการกำหนดค่า files ใช้หนึ่งใน vsftpd, httpd และ tftpd DHCP ใช้เพื่อจัดเตรียมตัวเลือกสำหรับ ZTP

รีเลย์ DHCP

หากเซิร์ฟเวอร์ ZTP และอุปกรณ์ที่จะอัปเกรดไม่ได้เชื่อมต่อโดยตรงบน LAN เดียวกัน จำเป็นต้องมีรีเลย์ DHCP ต้องเปิดใช้งานรีเลย์บนอุปกรณ์ใด ๆ ที่มีการเชื่อมต่อระหว่างอุปกรณ์ที่กำลังอัปเกรดและเซิร์ฟเวอร์ ZTP โดยใช้ CLI ต่อไปนี้:
ตั้งค่าตัวเลือกการส่งต่อการทดสอบกลุ่มเซิร์ฟเวอร์ dhcp-relay
ตั้งค่าตัวเลือกการส่งต่อ การทดสอบ dhcp-relay active-server-group ตั้งค่าตัวเลือกการส่งต่อ dhcp-relay group อินเทอร์เฟซทั้งหมด
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการกำหนดค่ารีเลย์ DHCP บนอุปกรณ์ Junos OS โปรดดูเอกสารต่อไปนี้:

การตั้งค่าเซิร์ฟเวอร์ DHCP และโหมดการขนส่ง

ดำเนินการตามขั้นตอนต่อไปนี้:

อ้างถึง https://linux.die.net/man/5/dhcpd.conf เพื่อทราบข้อมูลเพิ่มเติมเกี่ยวกับพารามิเตอร์และด้านล่างคือ sampกำหนดค่าของ /etc/dhcp/dhcpd.conf
- # อินเทอร์เฟซที่เซิร์ฟเวอร์ dhcp ฟัง ถึง dhcp ค้นพบข้อความ
  DHCPDARGS=ens33;
  # การประกาศด้านล่างใช้เพื่อระบุเครือข่ายย่อยที่
  การฟัง
  # สำหรับ dhcp ค้นพบข้อความและระบุที่อยู่ IP
  # range : ระบุจำนวนที่อยู่ IP ที่จะเช่า
  # ชื่อโดเมน : ใช้เพื่อระบุเครือข่าย เซิร์ฟเวอร์ชื่อโดเมน: ถูกใช้
  # เมื่อใช้ชื่อโฮสต์แทนที่อยู่ IP
  ซับเน็ต 3.3.3.0 เน็ตมาสก์ 255.255.255.0 {
  ช่วง 3.3.3.3 3.3.3.15;
  ตัวเลือกชื่อโดเมน “mydomain.net”;
  ตัวเลือกโดเมนเนมเซิร์ฟเวอร์ 10.209.194.133;
  ตัวเลือกเราเตอร์ 3.3.3.254;
  เวลาเช่าเริ่มต้น 60000;
  เวลาเช่าสูงสุด 720000;
  }
  # การประกาศด้านล่างให้คำจำกัดความของพื้นที่ตัวเลือก
  พื้นที่ตัวเลือก SUNW;
  ตัวเลือก SUNW.server-รหัสภาพ 0 = ข้อความ;
  ตัวเลือก SUNW.server-file รหัส 1 = ข้อความ;
  ตัวเลือก SUNW.image-file-พิมพ์รหัส 2 = ข้อความ;
  ตัวเลือก SUNW.transfer-mode รหัส 3 = ข้อความ;
  ตัวเลือก SUNW.symlink-server-image code 4 = ข้อความ;
  ตัวเลือก SUNW.http-รหัสพอร์ต 5 = ข้อความ;
  ตัวเลือกรหัสการห่อหุ้ม SUNW 43 = การห่อหุ้ม SUNW;
  # group ใช้เพื่อใช้พารามิเตอร์ทั่วไปสำหรับโฮสต์ที่แตกต่างกันจำนวนมาก
  # การกำหนดโฮสต์เฉพาะและพารามิเตอร์
  # “ฮาร์ดแวร์อีเธอร์เน็ต ” ที่อยู่ mac ของอุปกรณ์ สำหรับ MX10003 มันจะเป็น
  # มีที่อยู่ mac ของอินเทอร์เฟซ fxp0
  # โหมด “โหมดถ่ายโอน” ใช้สำหรับดาวน์โหลดรูปภาพและกำหนดค่า
  # fileส. หากไม่มีสิ่งนี้ ค่าเริ่มต้นคือ tftp ตัวเลือกคือ http, ftp และ tftp
  # log-server และ ntp-server ใช้สำหรับส่งข้อความ syslog
  # “server-image” คือรูปภาพของอุปกรณ์
  # “เซิร์ฟเวอร์-file ” เป็นตัวเลือกสำหรับการกำหนดค่า file.
  # “tftp-server-name” คือที่อยู่ IP ของเซิร์ฟเวอร์ที่ให้ files
  #สำหรับการบูต สิ่งนี้มีให้เป็นสตริง
  กลุ่ม {
  เซิร์ฟเวอร์ถัดไป 3.3.3.1;
  โฮสต์ mx204-12345 {
  hardware ethernet 98:a4:04:7f:1a:83;
  ตัวเลือก SUNW.transfer-mode “ftp”;
  ตัวเลือกชื่อโฮสต์ “mx204-12345″;
  ตัวเลือกล็อกเซิร์ฟเวอร์ 3.3.3.1;
  ตัวเลือกเซิร์ฟเวอร์ ntp 66.129.255.62;
  ตัวเลือก SUNW.server-file “dut-baseline-config.conf”;
  ตัวเลือก SUNW.server-image “junos-vmhost-install-mx-x86-64-
  19.4R1.1.tgz”;
  ตัวเลือก tftp-server-name “3.3.3.1”;
  ยึดตามรูปแบบข้อความหรือตัวเลขตามที่กล่าวไว้ข้างต้น ถ้าไม่เช่นนั้น dhcpd จะระบุข้อผิดพลาดเมื่อเริ่มต้นระบบ บันทึกการกำหนดค่า file และเริ่มบริการ dhcpd บันทึกที่เกี่ยวข้องกับ dhcpd อาจเป็นได้ viewเอ็ดใน /var/log/ข้อความ file.

คัดลอกรูปภาพและการกำหนดค่า file ไปยังเส้นทางที่เหมาะสมขึ้นอยู่กับโหมดการขนส่งที่กำหนดค่าไว้ ตารางด้านล่างนี้เป็นตัวอย่างampสมมติว่า /tftpboot/ ถูกใช้โดย tftp และ ftp สำหรับ file เก็บ. เซิฟเวอร์-file และตัวเลือกรูปภาพเซิร์ฟเวอร์ใน dhcpd.conf file จำเป็นต้องมีเส้นทางที่สัมพันธ์กับเส้นทางที่กำหนดค่าไว้สำหรับโหมดการขนส่ง

โหมดการขนส่ง	การกำหนดค่า File เส้นทาง	หน้าแรก
f`tp`	`/etc/vsftpd/vsftpd.conf`	`/tftpboot`
`tftp`	`/etc/xinet.d/tftp`	`/tftpboot`
http	/etc/http/conf/httpd.conf	/ var / www / html /

เช่นampหากรูปภาพอยู่ใน /tftpboot/PLATFORM_AA/image_aa.tgz ดังนั้น
ตัวเลือกเซิร์ฟเวอร์อิมเมจต้องเป็น /PLATFORM_AA/image_aa.tgz

หากมีการจัดเตรียมอุปกรณ์เริ่มต้นจากโรงงาน ให้ทำการเชื่อมต่อเครือข่ายและเปิดอุปกรณ์ เมื่ออุปกรณ์บูท การอัปเกรดรูปภาพอัตโนมัติ (AIU) จะเริ่มขึ้น
หากต้องจัดเตรียมอุปกรณ์ที่มีอยู่ วิธีที่ดีที่สุดคือทำให้อุปกรณ์เป็นศูนย์โดยใช้คำสั่ง "request system zeroize" พิมพ์ “ใช่” สำหรับพรอมต์แล้วกด Enter
อุปกรณ์มีค่าเป็นศูนย์แล้วรีบูต อุปกรณ์ปรากฏขึ้นในโหมดความจำเสื่อม เข้าสู่ระบบโดยใช้ root และไม่มีการแจ้งรหัสผ่าน หลังจากผ่านไปสองสามนาที มีข้อความบนคอนโซลระบุว่า ZTP ได้เริ่มทำงานแล้ว ออกคำสั่ง CLI “show dhcp clientbinding” เพื่อตรวจสอบ IP ที่ผูกกับ DHCP

ติดตามความคืบหน้าของ ZTP

ดำเนินการตามขั้นตอนต่อไปนี้:

ข้อความต่อไปนี้ระบุตัวเลือกที่ส่งโดยเซิร์ฟเวอร์ DHCP:
อัปเกรดอิมเมจอัตโนมัติ: ตัวเลือก DHCP INET สำหรับอินเทอร์เฟซไคลเอ็นต์ fxp0.0 การกำหนดค่าFile:
รูปภาพ baseline_mt-bonaFile: junos-vmhost-ติดตั้ง-mx-x86-64- 20.3R1.3.tgz
เกตเวย์: 17.17.34.1 เซิร์ฟเวอร์ DHCP: 17.17.34.1 File เซิฟเวอร์ : 17.17.34.1
จากนั้น AIU จะใช้ข้อมูลในตัวเลือก DHCP เพื่อดาวน์โหลดอิมเมจและการกำหนดค่า fileส. จากนั้นภาพก็จะถูกติดตั้ง หลังจากขั้นตอนการติดตั้งอิมเมจ AIU จะกำหนดค่าตัวเลือกเหตุการณ์เพื่อใช้การกำหนดค่าจากการกำหนดค่าที่ดาวน์โหลด file. ขั้นตอนสุดท้ายหลังจากติดตั้งอิมเมจใหม่แล้ว ให้ใช้การกำหนดค่า
ด้านล่างนี้คือภาพรวมของข้อความที่แสดงบนคอนโซลหลังจากได้รับตัวเลือก DHCP
ได้รับคะแนนแล้ว
อัปเกรดรูปภาพอัตโนมัติ: หากต้องการหยุด ให้ใช้ CLI
“ลบการอัพเกรดอิมเมจอัตโนมัติของแชสซี” และคอมมิต
อัปเกรดรูปภาพอัตโนมัติ: ใช้งานบนอินเทอร์เฟซไคลเอนต์ INET: fxp0.0
อัปเกรดรูปภาพอัตโนมัติ: อินเทอร์เฟซ:: “fxp0”
อัพเกรดอิมเมจอัตโนมัติ: เซิร์ฟเวอร์:: “17.17.34.1”
อัปเกรดรูปภาพอัตโนมัติ: รูปภาพ File:: “junos-vmhost-install-mx-x86-64-
20.3R1.3.tgz”
อัปเกรดรูปภาพอัตโนมัติ: กำหนดค่า File:: “baseline_mt-bona”
อัปเกรดรูปภาพอัตโนมัติ: เกตเวย์:: “17.17.34.1”
อัปเกรดรูปภาพอัตโนมัติ: โปรโตคอล:: “ftp”
อัปเกรดรูปภาพอัตโนมัติ: หมดเวลา FTP ตั้งค่าเป็น 300 วินาที
ต่อไปนี้เป็นข้อความที่แสดงเมื่อดาวน์โหลดและติดตั้งรูปภาพ:
อัปเกรดรูปภาพอัตโนมัติ: เริ่มดึงข้อมูล baseline_mt-bona file จากเซิร์ฟเวอร์
17.17.34.1 ถึง fxp0 โดยใช้ ftp
อัปเกรดรูปภาพอัตโนมัติ: File baseline_mt-bona ดึงมาจากเซิร์ฟเวอร์
17.17.34.1 ถึง fxp0
อัปเกรดรูปภาพอัตโนมัติ: หมดเวลา FTP ตั้งค่าเป็น 300 วินาที
อัปเกรดอิมเมจอัตโนมัติ: เริ่มดึงข้อมูล junos-vmhost-install-mx-x86-64-
20.3R1.3.tgz file จากเซิร์ฟเวอร์ 17.17.34.1 ถึง fxp0 โดยใช้ ftp
อัปเกรดรูปภาพอัตโนมัติ: File junos-vmhost-ติดตั้ง-mx-x86-64-20.3R1.3.tgz
ดึงมาจากเซิร์ฟเวอร์ 17.17.34.1 ถึง fxp0
อัปเกรดอิมเมจอัตโนมัติ: การยกเลิกการติดตั้งอิมเมจของ junos-vmhostinstall-mx-x86-64-20.3R1.3.tgz ที่ได้รับตั้งแต่ 17.17.34.1 ถึง
fxp0: ติดตั้งและดึงข้อมูลรูปภาพเวอร์ชันเดียวกัน
อัปเกรดรูปภาพอัตโนมัติ: การใช้ baseline_mt-bona file การกำหนดค่า
ดึงมาจากเซิร์ฟเวอร์ 17.17.34.1 ถึง fxp0
ต่อไปนี้เป็นข้อความจาก /var/log/ข้อความ file ที่แสดงที่อยู่ IP ที่ได้รับการจัดสรรให้กับอุปกรณ์
26 ก.ย. 04:11:41 mx-phs-server1 dhcpd: DHCPREQUEST สำหรับ 17.17.34.110
จาก e4:fc:82:0f:d2:00 (TC3718210039) ผ่าน eth1
26 ก.ย. 04:11:42 mx-phs-server1 dhcpd: DHCPACK บน 17.17.34.110 ถึง
e4:fc:82:0f:d2:00 (TC3718210039) via eth1
26 ก.ย. 05:11:41 mx-phs-server1 dhcpd: ผู้ขาย-Class-Identifier:
จูนิเปอร์:ex4600-40f:TC3718210039
26 ก.ย. 05:11:42 mx-phs-server1 dhcpd: DHCPREQUEST สำหรับ 17.17.34.110
จาก e4:fc:82:0f:d2:00 (TC3718210039) ผ่าน eth1
26 ก.ย. 05:11:42 mx-phs-server1 dhcpd: DHCPACK บน 17.17.34.110 ถึง
e4:fc:82:0f:d2:00 (TC3718210039) via eth1
ขั้นตอนสุดท้ายหลังจากติดตั้งอิมเมจแล้ว ให้ใช้การกำหนดค่า เรียกใช้ “แสดงระบบคอมมิต” เพื่อตรวจสอบผลลัพธ์ อุปกรณ์จะต้องมีการกำหนดค่าที่ถูกต้องในตอนท้าย สำหรับบันทึกการติดตั้งโดยละเอียด คุณสามารถตรวจสอบได้ที่ /var/log/image_load_log file.

การตรวจสอบ

หากต้องการตรวจสอบว่าอุปกรณ์ได้รับที่อยู่ IP จากเซิร์ฟเวอร์ DHCP ให้รันคำสั่งต่อไปนี้: root@host> แสดงการเชื่อมโยงไคลเอ็นต์ dhcp
ในเอาต์พุต สถานะ DHCP จะต้องแสดง “BOUND”
root@host>แสดงบันทึก image_load_log
ผลลัพธ์จะแสดงความคืบหน้าของกระบวนการโหลดรูปภาพ ZTP

การแก้ไขปัญหา

ดำเนินการตามขั้นตอนต่อไปนี้:

ตรวจสอบให้แน่ใจว่าการเชื่อมต่อใช้งานได้ เนื่องจากข้อความการค้นพบ DHCP ได้รับการเผยแพร่ เครือข่ายจึงต้องส่งต่อข้อความการค้นพบ DHCP เหล่านี้ไปยังเซิร์ฟเวอร์ DHCP
สถานะกระบวนการ dhcpd จะต้องทำงานหรือใช้งานอยู่ ถ้าไม่เช่นนั้นให้ตรวจสอบ /var/log/ข้อความ file เพื่อตรวจสอบปัญหา ใช้เหมือนกัน file เพื่อค้นหารายการ DHCP
เพื่อตรวจสอบว่า DHCP ค้นพบข้อความถึงเซิร์ฟเวอร์ DHCP หรือไม่ ณ จุดนี้ อุปกรณ์ควรได้รับการกำหนดที่อยู่ IP
ข้อความ DHCP ใน /var/log/messages ควรเกี่ยวข้องกับที่อยู่ mac ของอินเทอร์เฟซ fxp0/em0 หากไม่มีอยู่ DHCP จะค้นพบข้อความจากอุปกรณ์ที่ไปไม่ถึงเซิร์ฟเวอร์
ตรวจสอบว่าอินเทอร์เฟซ fxp0/em0 ได้รับที่อยู่ IP ดังที่แสดงในเอาต์พุตคำสั่ง “show dhcp clientbinding”
นอกจากที่อยู่ IP แล้ว อุปกรณ์จะต้องได้รับข้อมูลเกี่ยวกับรูปภาพด้วย file, การกำหนดค่า file, IP ของเซิร์ฟเวอร์ และโหมดการขนส่งที่จะใช้เพื่อจัดเตรียมอุปกรณ์
หากได้รับเฉพาะที่อยู่ IP โดยไม่มีตัวเลือก ตรวจสอบให้แน่ใจว่ามีตัวเลือก "tftp-server-name" หรือ "server-name" ปรากฏอยู่ หากไม่มีทั้งสองสิ่งนี้ dhcpd จะไม่ส่งตัวเลือกเพิ่มเติม หากมีการเปลี่ยนแปลงการกำหนดค่าใดๆ files จะต้องเริ่มบริการที่เกี่ยวข้องใหม่เพื่อให้การเปลี่ยนแปลงมีผล
หากได้รับตัวเลือกแล้วแต่มีปัญหาในการดาวน์โหลดรูปภาพหรือการกำหนดค่า fileให้ตรวจสอบการกำหนดค่าสำหรับบริการที่เกี่ยวข้อง สampการกำหนดค่าและการตั้งค่าจะแสดงด้านล่างสำหรับการติดตั้ง Centos 6.x
Sampตัวเลือก le vsftd.conf ที่เปิดใช้งานเพื่อรองรับ ztp
anonymous_enable = ใช่
local_enable = ใช่
local_root=/tftpboot/
write_enable = ใช่
local_umask=022
anon_upload_enable=ใช่
anon_mkdir_write_enable=ใช่
dirmessage_enable=ใช่
xferlog_enable=ใช่
xferlog_std_format=ใช่
ascii_upload_enable=ใช่
ascii_download_enable=ใช่
Allow_writeable_chroot=ใช่
ls_recurse_enable=ใช่
ฟัง=ใช่
pam_service_name=vsftpd
userlist_enable=ไม่ใช่
userlist_deny=ไม่ใช่
tcp_wrappers=ใช่
anon_root=/tftpboot/
Sampตัวเลือก httpd.conf สำหรับการรองรับ ztp
ServerRoot “/etc/httpd” Listen : ผู้ใช้ daemon กลุ่ม daemon EnableSendfile on
Sampตัวเลือก tftp สำหรับการรองรับ ztp ใน
/etc/xinetd.d/tftp
server_args = -s /tftpboot/
ปิดการใช้งาน = n
ลีนุกซ์รุ่นใหม่ล่าสุด (เช่นample, Centos 7 หรือใหม่กว่า) มีไฟร์วอลล์ทำงานโดย Configure เพื่ออนุญาตการเข้าถึงบริการเหล่านี้
ดูรายละเอียดขั้นตอนนี้เพิ่มเติมได้ที่ https://www.juniper.net/documentation/us/en/software/junos/junos-install- อัพเกรด/หัวข้อ/topic-map/zero-touch-provision.html

สวิตช์ RE คู่เท่านั้น

ขั้นตอน ZTP สามารถใช้กับสวิตช์ RE คู่ได้ มีขั้นตอนอื่นๆ สำหรับสวิตช์ RE คู่เช่นกัน
นสส

ISSU ใช้สำหรับสวิตช์ RE คู่เท่านั้น และรวม GRES เข้ากับ NSR สมมติฐานมีดังนี้:

- พื้นที่ดิสก์พร้อมใช้งานสำหรับ /var file ระบบบน Routing Engine ทั้งสองเครื่อง
- การกำหนดค่าได้รับการสนับสนุนโดย ISSU แบบรวมศูนย์
- PIC ได้รับการสนับสนุนโดย ISSU แบบครบวงจร
- เปิดใช้งานการสลับกลไกการกำหนดเส้นทางอย่างสง่างามแล้ว
- เปิดใช้งานการกำหนดเส้นทางที่ใช้งานแบบไม่หยุดยั้งสำหรับ VC/VCF แต่ ISSU ไม่ได้เปิดใช้งาน
  สำหรับข้อมูล ISSU โปรดดู https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/topic- แผนที่/ฉบับ-understand.html.
  สำหรับข้อกำหนดในการดำเนินการ ISSU โปรดดู https://www.juniper.net/documentation/us/en/software/junos/high- ความพร้อมใช้งาน/หัวข้อ/แนวคิด/ISSU-system-requirements.html
  สำหรับคำแนะนำโดยละเอียดในการดำเนินการ ISSU โปรดดู https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/topic- แผนที่/ฉบับ-performing.html
  สำหรับ ISSU เรารองรับการอัปเกรดจากเวอร์ชัน N เป็น N+3 สำหรับเช่นampหากเวอร์ชัน Junos OS ปัจจุบันคือ 19 เวอร์ชันอัปเกรดที่แนะนำคือสูงสุด 19+3 = 22

บันทึก: PIC เดิมบางอันไม่รองรับ ISSU PIC ที่ออฟไลน์หลังจาก ISSU จะต้องเปิดออนไลน์ด้วยตนเอง

บทที่ 5 การอัพเกรดตาม Juniper Apstra

อัปเกรดสวิตช์ด้วยซอฟต์แวร์ Juniper Apstra

ขั้นตอนในการระบายการรับส่งข้อมูลจากสวิตช์ผ่าน Apstra มีระบุไว้ที่นี่: https://www.juniper.net/documentation/us/en/software/apstra4.1/apstra-user- คู่มือ/หัวข้อ/งาน/device-drain.html
วิดีโอสำหรับเรื่องเดียวกันนี้มีอยู่ที่: https://www.youtube.com/watch?v=cpk-0eZ_L_U.
สำหรับขั้นตอนการอัพเกรดสวิตช์ โปรดดูที่ https://www.juniper.net/documentation/us/en/software/apstra4.1/apstra-user-guide/topics/topic- แผนที่/อุปกรณ์-nos-upgrade.html

บทที่ 6 การย้อนกลับซอฟต์แวร์ Junos OS

ซอฟต์แวร์ย้อนกลับ Junos OS

ดำเนินการตามขั้นตอนต่อไปนี้:

ติดต่อฝ่ายสนับสนุนลูกค้าเพื่อขอสัญญาณเตือนและคอร์ดัมพ์ระหว่าง/หลังการอัพเกรด
- ระบุบันทึกระบบ file “ข้อความ” และแกนกลาง files
ในกรณีที่การอัปเกรดสวิตช์ล้มเหลวเนื่องจาก ISSU สวิตช์จะย้อนกลับไปเป็นอิมเมจ Junos OS / Junos OS Evolved ดั้งเดิมโดยอัตโนมัติ ในกรณีของ NSSU อาจเป็นไปได้ว่าสวิตช์บางตัวที่เป็นของ VC/VCF ได้รับการอัปเกรดเป็นอิมเมจ Junos OS ที่ใหม่กว่าได้สำเร็จ ในขณะที่สวิตช์ที่เหลือไม่อัปเกรด ในกรณีเช่นนี้ คุณต้องย้อนกลับสวิตช์ที่อัปเกรดใหม่ไปเป็นอิมเมจ Junos OS ดั้งเดิมด้วยตนเองผ่านคำสั่งต่อไปนี้:
- ขอการย้อนกลับซอฟต์แวร์ระบบ
- ขอให้ระบบรีบูต
  จากนั้น คุณสามารถติดต่อฝ่ายสนับสนุนลูกค้าเพื่อขอความช่วยเหลือในการอัพเกรดสวิตช์ที่ล้มเหลวในกระบวนการอัปเกรด

ที่ตีพิมพ์
2023-05-11

เอกสาร / แหล่งข้อมูล

Juniper NETWORKS อัพเกรด IP Fabric ขั้นต่ำ [พีดีเอฟ] คู่มือการใช้งาน
การอัพเกรด IP Fabric ขั้นต่ำ, IP, การอัพเกรด Fabric ขั้นต่ำ, การอัพเกรดขั้นต่ำ

อ้างอิง

คู่มือการใช้งาน

การกำหนดค่าเครือข่าย เช่นample

บทที่ 1 การอัพเกรด IP Fabric สิ้นสุดลงview

เกี่ยวกับการกำหนดค่านี้ เช่นample

บทที่ 2 วางแผนการอัพเกรดสวิตช์ในสถาปัตยกรรม IP Fabric

บทที่ 3 สถาปัตยกรรมการปรับใช้

บทที่ 4 อัปเกรดด้วยตนเองสำหรับสวิตช์ที่ไม่มี Juniper Apstra

ขั้นตอนทั่วไปสำหรับการอัพเกรดสวิตช์

แพลตฟอร์มที่รองรับสำหรับขั้นตอนการอัพเกรดด้วยตนเอง (ไม่มี Juniper Apstra)

รายละเอียดการอัปเกรดด้วยตนเองสำหรับสวิตช์ที่ไม่มี Juniper Apstra

การแก้ไขปัญหา

บทที่ 5 การอัพเกรดตาม Juniper Apstra

อัปเกรดสวิตช์ด้วยซอฟต์แวร์ Juniper Apstra

บทที่ 6 การย้อนกลับซอฟต์แวร์ Junos OS

ซอฟต์แวร์ย้อนกลับ Junos OS

เอกสาร / แหล่งข้อมูล

อ้างอิง

ฝากความคิดเห็น

ยกเลิกการตอบ