Juniper NETWORKS IP Fabric Upgrade Minimum User Guide

 

Network Configuration Halample

—————————————————————
IP Fabric Upgrade Minimum Operating Procedure

Juniper Networks, Inc.
1133 Paraan ng Pagbabago
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net

Ang Juniper Networks, ang logo ng Juniper Networks, Juniper, at Junos ay mga rehistradong trademark ng Juniper Networks, Inc. sa United States at iba pang mga bansa. Ang lahat ng iba pang mga trademark, mga marka ng serbisyo, mga rehistradong marka, o mga rehistradong marka ng serbisyo ay pag-aari ng kani-kanilang mga may-ari.

Ang Juniper Networks ay walang pananagutan para sa anumang mga kamalian sa dokumentong ito. Inilalaan ng Juniper Networks ang karapatang baguhin, baguhin, ilipat, o kung hindi man ay baguhin ang publikasyong ito nang walang abiso.

Network Configuration Halampang IP Fabric Upgrade Minimum Operating Procedure Copyright © 2023 Juniper Networks, Inc. All rights reserved.

Ang impormasyon sa dokumentong ito ay kasalukuyang sa petsa sa pahina ng pamagat.

TAONG 2000 PAUNAWA
Ang mga produkto ng hardware at software ng Juniper Networks ay sumusunod sa Year 2000. Ang Junos OS ay walang alam na limitasyong nauugnay sa oras hanggang sa taong 2038.
Gayunpaman, ang NTP application ay kilala na may ilang kahirapan sa taong 2036.

END USER LICENSE AGREEMENT
Ang produkto ng Juniper Networks na paksa ng teknikal na dokumentasyong ito ay binubuo ng (o nilayon para gamitin sa) Juniper Networks software.
Ang paggamit ng naturang software ay napapailalim sa mga tuntunin at kundisyon ng End User License Agreement (“EULA”) na naka-post sahttps://support.juniper.net/support/eula/. Sa pamamagitan ng pag-download, pag-install o paggamit ng naturang software, sumasang-ayon ka sa mga tuntunin at kundisyon ng EULA na iyon.

CHAPTER 1 IP Fabric Upgrade Overview

Tungkol sa Configuration na Ito Halample

Tapos naview
Gamitin itong network configuration halample (NCE) upang i-upgrade ang lahat ng switch sa isang IP Fabric architecture na gumagana na.
Feedback sa Dokumentasyon 

Hinihikayat ka naming magbigay ng feedback upang mapagbuti namin ang aming dokumentasyon.
Ipadala ang iyong mga komento sa design-center-comments@juniper.net. Isama ang pangalan ng dokumento o paksa, URL o numero ng pahina, at bersyon ng software (kung naaangkop).

CHAPTER 2 Plan Upgrade para sa mga Switch sa isang IP Fabric Architecture

Pagpaplano ng Pag-upgrade 

• Sinasaklaw ng seksyong ito ang mga alituntunin para sa pagpaplano ng pag-upgrade.
• Palaging mag-upgrade ng isang device sa isang pagkakataon sa unang yugto. Pagkatapos ng ilang matagumpay na pag-upgrade at pagbuo ng pamilyar sa pamamaraan, maaari mong i-upgrade ang mga switch sa mga batch, na may maraming switch ng dahon nang sabay-sabay, para sa malaking deployment. Inirerekomenda na ang spine at super-spine switch ay dapat na i-upgrade nang paisa-isa, upang maiwasan ang anumang pagkagambala sa trapiko kung sakaling walang mga redundant na landas.
• Suriin ang kasalukuyang paggamit ng bandwidth ng lahat ng mga link sa network.
• Maaaring gamitin ang parehong in-band at out-of-band na mga pamamaraan sa pag-upgrade. Kung kahit isang switch sa IP fabric ay gumagamit ng ZTP based upgrades sa pamamagitan ng in-band procedure, ang DHCP relay ay kailangang i-configure sa lahat ng switch sa IP Fabric. Ito ay upang matiyak na ang switch na ina-upgrade ay may patuloy na access sa DHCP server para sa software image at switch configuration download. Kung ang lahat ng switch sa IP Fabric ay ina-upgrade sa pamamagitan ng ISSU/NSSU, hindi na kailangang i-configure ang DHCP relay sa anumang switch sa IP Fabric para sa in-band procedure.
• Mayroong ilang mga CLI show command na ginagamit, at ang impormasyon ay kinokolekta. Inirerekomenda na i-automate ang mga utos ng CLI sa mga script at iimbak ang lahat ng impormasyon sa server. Gumamit ng mga tool upang mabilis na maghanap at maghambing ng mga detalye sa nakolektang impormasyon.
• Tukuyin at idisenyo ang ilang daloy ng trapiko na maaaring patunayan ang pagkakakonekta ng network at maaaring tumakbo sa background sa panahon ng pag-upgrade. Ang ping at traceroute ay karaniwang ginagamit para sa layuning ito.
• Magplano ng sapat na oras para sa maintenance window (MW). Maaaring kailanganin ang maraming MW para sa malaking deployment. Palaging mag-upgrade ng isang device sa isang pagkakataon sa unang yugto. Pagkatapos ng ilang matagumpay na pag-upgrade at pagiging pamilyar sa pamamaraan, ang pag-upgrade ay maaaring gawin sa mga batch na may maraming switch ng dahon nang sabay-sabay para sa malaking deployment.
• Iskedyul ang pagbabago sa lahat ng mga koponan at indibidwal na apektado ng pagbabago.
• Sinusuportahan ng dokumentong ito ang multi-homing ng isang server host sa iba't ibang top-of-rack (TOR) o mga switch ng dahon gamit ang LACP based na LAG na koneksyon.

CHAPTER 3 Deployment Architectures

DC IP Routed na Tela 5 Stage Clos na may Super Spine

Kasama sa arkitektura na ito ang DC IP Routed Fabric 5 Stage Clos na may Super Spine na may eBGP bilang fabric protocol sa bawat layer sa iba't ibang AS.
Figure 1: IP Fabric Topology na may EBGP Fabric Protocol, na may Bawat Layer sa Iba't ibang AS
Routed Tela na may Super Spine Architecture
Mga Sinusuportahang Platform
Talahanayan 1 naglilista ng mga sinusuportahang platform para sa iba't ibang tungkulin sa IP Fabric.
Talahanayan 1: Mga Sinusuportahang Platform para sa IP Fabric 

Mga Tungkulin sa Device	Mga plataporma
Dahon/TOR	QFX5130-32CD QFX5220-32CD /128C QFX5120-32C/48Y/48T/48YM QFX5100/QFX5110-48S QFX5200-32C QFX5210-64C ACX7100-48L
Gulugod	QFX5220-32CD/128C PTX10K8 /16

Mga Tungkulin sa Device	Mga plataporma
	QFX5120-32C QFX5210-64C QFX5130-32CD QFX5700 QFX5200-32C PTX10003 QFX5110-32Q
Super Spine	QFX5220-128C PTX10K8/PTX10K3 QFX5210-64C QFX10K8/16

TANDAAN: Sa mga nakalistang sinusuportahang platform, ang PTX10K8/16, QFX5700, QFX10K8/16 ay mga chassis based modular system. Ang mga natitirang platform ay fixed form factor na may sukat na 1, 2, o 3 Rack units (RUs).

Mga Tungkulin sa Node
Sa Figure 1, ang mga sumusunod ay ang mga tungkulin ng node:

• Ang P1L1, P1L2, P1L3 at P1L4 ay ang mga leaf node sa POD-1.
• Ang P2L2, P2L2, P2L3 at P2L4 ay ang mga leaf node sa POD-2.
• Ang P1S1, P1S2, P1S3, P1S4 ay ang mga spine node sa POD-1.
• Ang P2S1, P2S2, P2S3, P2S4 ay ang mga spine node sa POD-2.
• Ang SS1, SS2, SS3, SS4 ay ang mga super spine sa super spine layer, na karaniwan sa POD-1 at POD-2.

Lumipat ng mga Configuration

Inaasahan na ang IP Fabric ay nagpapatakbo ng mga pangunahing minimum na configuration na kinakailangan upang gawin itong gumana. Tingnan ang Figure 1. Narito ang kaunting paglalarawan ng mga kinakailangan sa pagsasaayos:

• Ang tela ay na-configure para sa dalawahang stack na may parehong IPv4 at IPv6 routing sa tela.
• Ang lahat ng mga link sa tela ay P2P at naka-configure para sa parehong IPv4 at IPv6.
• Ang eBGP ay ginagamit bilang routing protocol.
• Ginagamit ang eBGP peer group, lahat ng leaf switch ay nabibilang sa 1 eBGP peer group (sabihin, LEAF), lahat ng spine switch ay nabibilang sa 1 eBGP peer group (sabihin, SPINE) at lahat ng super-spine switch ay nabibilang sa 1 eBGP peer group (sabihin SUPER-SPINE).
• Maaaring pinagsama-sama ang mga ruta bago i-advertise sa pamamagitan ng eBGP.
• Ang bidirectional na trapiko ay dumadaloy sa lahat ng switch sa IP fabric.

KABANATA 4 Manu-manong Pag-upgrade para sa Mga Switch na Walang Juniper Apstra

Mga Alituntunin para sa Pag-upgrade ng Layer ayon sa Layer
Sa bawat layer, tukuyin ang lahat ng karaniwang ginagamit na platform, para matukoy ang anumang pagbubukod na nauugnay sa pag-upgrade para sa iba pang mga platform.

Unang Hakbang – I-upgrade ang Mga TOR (Edge Switch)
I-upgrade ang lahat ng TOR nang paisa-isa. Ipinapalagay na ang lahat ng TOR ay iisang RE device at samakatuwid ang TOR na ina-upgrade ay hindi magagamit sa panahon ng pag-upgrade para sa pagpapasa ng landas ng data. Kung sakaling ang isang server ay konektado sa isang TOR lamang na ina-upgrade, i-migrate ang mga VM sa mga server na nakakonekta sa mga TOR na hindi ina-upgrade.

Ikalawang Hakbang – I-upgrade ang Mga Leaf Device
I-upgrade ang lahat ng leaf switch, isa-isa: leaf1, leaf2, leaf3, at iba pa. Para sa dalawahang RE switch, gamitin ang pamamaraang ISSU o NSSU.

Ikatlong Hakbang – I-upgrade ang Spines
I-upgrade ang lahat ng spine switch, isa-isa: spine1, spine2, spine3, at iba pa. Para sa dalawahang RE switch, gamitin ang pamamaraang ISSU o NSSU.

Ika-apat na Hakbang – I-upgrade ang Super-Spines
I-upgrade ang lahat ng super-spine switch, isa-isa: super-spine1, super-spine2, super-spine3, at iba pa. Para sa dalawahang RE switch, gamitin ang pamamaraang ISSU o NSSU.

Karaniwang Pamamaraan para sa Pag-upgrade ng Switch

Pre-Upgrade at Post-Upgrade Health Checking

Inirerekomenda namin ang pagsusuri sa kalusugan ng switch na ina-upgrade, parehong pre-upgrade at postupgrade, at i-record ang impormasyong ito. Ang naitala na impormasyon sa pagsusuri sa kalusugan ng pre-upgrade at post upgrade ay maaaring ihambing sa kaganapan ng isang isyu.

Pamamaraan ng Pagsusuri ng Kalusugan
Gawin ang mga sumusunod na hakbang:

1.  Suriin kung ang daloy ng trapiko ng gumagamit ay tulad ng inaasahan, nang walang anumang pagkawala bago at pagkatapos ng pag-upgrade.
2.  I-backup ang lahat ng mga configuration ng device at i-save ang mga ito sa isang server bago ang pag-upgrade.
3.  Mangolekta ng detalyadong impormasyon at suriin na ang system ay nasa malusog na estado bago at pagkatapos ng pag-upgrade.
   • Suriin ang syslog para sa anumang pagkabigo at mga error
   • ipakita ang mga mensahe ng log | wala na
   • ipakita ang log chassisd | wala na
   • Suriin ang mga alarma at core-dump sa system
     ipakita ang mga chassis alarm | wala na
     ipakita ang mga alarma ng system | wala na
     ipakita ang system core-dumps | wala na
   • Suriin ang RE/FPC/PIC status at mga interface status (para sa lahat ng platform na sinusuportahan)
     ipakita ang detalye ng chassis hardware | wala na
     ipakita ang detalye ng chassis fpc | wala na
     ipakita ang chassis fpc pic-status | wala na
     ipakita ang kapaligiran ng chassis | wala na
     ipakita ang chassis routing-engine | wala na
     ipakita ang mga paglalarawan ng mga interface | magkatugma | wala na
     ipakita ang mga paglalarawan ng mga interface | tugma pababa | wala na
     ipakita ang interface xe-* | tumugma sa "pisikal | rate" | wala na
     ipakita ang interface et-* | tumugma sa "pisikal | rate" | wala na
     Sa mga modular na platform na nakabatay sa chassis, maaari mo ring patakbuhin ang mga CLI na nauugnay sa tela:
     ipakita ang buod ng tela ng tsasis | wala na
     ipakita ang chassis fabric fpcs | wala na
     Para sa dalawahang RE switch, kailangan nating suriin ang kahandaan ng switchover para sa ISSU/NSSU:
     a. Sa kaso ng dalawahang RE switch, ang backup na RE ay dapat na handa na GRES.
     b. Suriin ang Master RE : “Switchover Ready” ready status sa pamamagitan ng pagpapatakbo ng command na “request chassis routing-engine master switch check”
     c. Patakbuhin ang command na "show system switchover" sa Backup RE at tiyaking nasa ready state na ito.
   • Suriin ang routing table at forwarding table, ang mga ito ay dapat tulad ng inaasahan:
     ipakita ang mga proseso ng system ng malawak na | wala na
     ipakita krt queue | wala na
     ipakita ang buod ng ruta | wala na
     ipakita ang buod ng pagpapasa-talahanayan ng ruta | wala na
     ipakita ang arp no-resolve expiration-time | wala na
     Sa ARP CLI sa itaas, ang no-resolve ay nagpapahiwatig na hindi namin gustong magsagawa ng mga DNS lookup para sa bawat entry sa ARP table. Kaya, nang walang paglutas, nakikita lang namin ang mga IP address, na maaaring mas mabilis kapag mayroon kang ilang mga entry sa ARP.
   • Suriin at iimbak ang detalyadong impormasyon ng impormasyong nauugnay sa tela ng IP (para sa lahat ng sinusuportahang platform):
   • ipakita ang pfe statistics traffic | wala na
   • ipakita ang system virtual-memory | wala na
   • ipakita ang detalye ng memorya ng gawain | wala na
   • ipakita ang memorya ng system | wala na
   • ipakita ang memorya ng gawain | wala na
   • ipakita ang chassis fpc | wala na
   • ipakita ang chassis routing-engine | wala na
   • ipakita ang mga proseso ng system ng malawak na | wala na
   • ipakita ang mga proseso ng system na detalye ng memorya | wala na
   • ipakita ang buod ng bgp | wala na
   • ipakita ang mga interface ae* maikli | wala na
   • ipakita ang mga interface ng lacp
   • ipakita ang mga interface ng istatistika ng lacp
   • ipakita ang mga interface na maikli |no-more
   • ipakita ang bfd session | wala na
     Sa mga modular platform na nakabatay sa chassis, maaari mong patakbuhin ang command na nauugnay sa Switch Interface Board (SIB):
     ipakita ang chassis mga kapatid | wala na
     Magsagawa ng anumang mga customized na pagsusuri at mga pamamaraan sa paghahanda para sa nakaplanong upgrade device, pagkatapos matapos ang pagsusuri sa kalusugan. Ang mga pagsusuring ito ay dapat gawin bago ang pamamaraan ng pag-upgrade na nakalista sa mga sumusunod na seksyon ng dokumentong ito.

Paghahanda para sa Pag-upgrade 

Gawin ang mga sumusunod na hakbang:

1. Suriin ang libreng storage ng system upang matiyak ang sapat na storage para sa bagong larawan ng Junos OS:
   • Patakbuhin ang "df -k /var/tmp" sa shell mode para sa pagsuri ng libreng espasyo.
   • Kung sakaling, ang libreng espasyo ay mas mababa kaysa sa kinakailangang espasyo para sa pag-upgrade, pagkatapos ay maaari tayong magbakante ng espasyo gamit ang command na nakalista sa hakbang 2. Para sa ZTP, walang ganoong kinakailangang libreng espasyo.
2. Patakbuhin ang "request system storage cleanup dry-run" sa tabi upang suriin ang iminungkahing listahan ng filepara sa pagtanggal:
3. Gamitin ang command na "request system storage cleanup " para magbakante ng storage space sa mga device kung ang iminungkahing listahan ng files na tatanggalin ay katanggap-tanggap. 3. I-clear ang anumang mga alarma at
   • mga core-dumps bago ang pag-upgrade: o i-clear ang mga error sa system fpc lahat ng fpc-slot 4
4. Kopyahin ang imahe ng Junos OS sa direktoryo ng device /var/tmp. Gamitin lang ang hakbang na ito kung hindi ginagamit ang phone-home o ZTP.

Pre-Upgrade BGP Specific Operations sa Spine
Gawin ang mga sumusunod na hakbang:

1. Ipinapalagay na ang bawat switch na ina-upgrade ay may mga sumusunod na parameter ng BGP na paunang na-configure:
   • delay-route-advertisement minimum-delay inbound-convergence
   • delay-route-advertisement minimum-delay routing-uptime
     Ito ay upang matiyak na ang mga ruta ng BGP ay ina-advertise sa pamamagitan ng isang switch pagkatapos ng power on, pagkatapos lamang na matiyak ang convergence ng ruta sa lokal na switch. Nangangahulugan ito na ang mga ruta sa RIB ay na-download na sa FIB ng switch. Kung sakaling ang mga ruta sa RIB ay hindi magagamit sa FIB, ang lokal na router ay magsisimula ng mga ruta sa pag-advertise kaagad pagkatapos na ang mga ruta ay magagamit sa RIB, kahit na ang FIB ay hindi maipasa ang mga ito. Maaari itong humantong sa pagbaba ng trapiko para sa mga destinasyon na ang mga ruta ay na-advertise ng lokal na router, ngunit kung saan walang katumbas na ruta sa FIB ng lokal na router.
     Ang kahulugan ng mga parameter ng BGP ay ang mga sumusunod: 
     inbound convergence – Tukuyin ang isang minimum na pagkaantala sa advertisement ng ruta pagkatapos na maipadala ng source peer ang lahat ng mga update sa ruta sa lokal na router na ina-upgrade. Ang lokal na device na ina-upgrade ay naghihintay ng hindi bababa sa naka-configure na tagal pagkatapos makumpleto ang inbound convergence sa lokal na device para sa source peer. Para sa mga ruta ng BGP, ipinapadala ng source peer ang end-of-rib pagkatapos maipadala ang lahat ng update sa ruta sa lokal na device. Ang default na halaga ay 120 segundo, ang hanay ay 1 hanggang 36000 segundo.
     Kung ang lahat ng BGP peer ng device ay nasa uri ng IPv4, patakbuhin ang sumusunod na command:
   • magtakda ng mga protocol bgp family inet unicast delay-route advertisement minimum-delay inbound-convergence <1 hanggang 36000 s>
     Kung ang lahat ng BGP peer ng device ay nasa uri ng IPv6, patakbuhin ang sumusunod na command:
   • magtakda ng mga protocol bgp family inet6 unicast delay-routeadvertisements minimum-delay inbound-convergence <1 to 36000 s>
     Kung ang ilan sa mga BGP peer ng device ay may uri ng IPv4, at ang ilan ay nasa uri ng IPv6, kung gayon ang inbound-convergence sa lokal na device ay kailangang itakda sa per-peer na batayan. Para sa mga IPv4 BGP peer, patakbuhin ang sumusunod na command:
   • magtakda ng mga protocol bgp group neighbor family inet unicast delay-routeadvertisements minimum-delay inbound-convergence <1 to 36000 s>
     Para sa mga IPv6 BGP peer, patakbuhin ang sumusunod na command: 
   • magtakda ng mga protocol bgp group neighbor family inet6 unicast delay-routeadvertisements minimum-delay inbound-convergence <1 to 36000 s>
     b) minimum na oras ng pagruruta – Tukuyin ang pinakamababang pagkaantala, sa mga segundo, bago magpadala ng advertisement ng ruta pagkatapos magsimula ang proseso ng routing protocol (rpd). Ang device ay naghihintay ng hindi bababa sa naka-configure na tagal bago magpadala ng mga advertisement ng ruta sa mga kapantay nito. Ang default na halaga ay 0 segundo, ang hanay ay 1 hanggang 36000 segundo.
     Kung ang lahat ng BGP peer ng device ay nasa uri ng IPv4, patakbuhin ang sumusunod na command:
   • magtakda ng mga protocol bgp family inet unicast delay-routeadvertisements minimum-delay routing-uptime <1 hanggang 36000 s>
     Kung ang lahat ng BGP peer ng device ay nasa uri ng IPv6, patakbuhin ang sumusunod na command: 
   • magtakda ng mga protocol bgp family inet6 unicast delay-routeadvertisements minimum-delay routing-uptime <1 to 36000 s>
     Kung ang ilan sa mga BGP peer ng device ay nasa uri ng IPv4, at ang ilan ay nasa uri ng IPv6, ang routing-uptime sa lokal na device ay dapat itakda sa per-peer na batayan. Para sa mga IPv4 BGP peer, patakbuhin ang sumusunod na command:
   • magtakda ng mga protocol bgp group neighbor family inet unicast delay-routeadvertisements minimum-delay routing-uptime <1 to 36000 s>
     Para sa mga IPv6 BGP peer, patakbuhin ang sumusunod na command: 
   • magtakda ng mga protocol bgp group neighbor family inet6 unicast delay-routeadvertisements minimum-delay routing-uptime <1 to 36000 s>
     Para sa karagdagang impormasyon, tingnan, https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/ref/statement/ delay-route-advertisements-edit-protocols-group-family-unicast.html
2. Kung ang anumang switch ng peer ng BGP ay nagpapadala ng trapiko sa device, tandaan ang incremental na egress na istatistika ng trapiko (mga packet ng output) sa mga nakakonektang interface ng device ng switch nito. Kung sakaling mayroong pinagsama-samang interface ng ethernet, sa pagitan ng peer switch at device na ito, tukuyin ang bumubuo ng mga pisikal na interface gamit ang sumusunod na command sa peer switch:
   • ipakita ang mga interface ng lacp
     Subaybayan ang egress traffic rate sa mga pisikal na interface ng peer switch, na konektado sa device, gamit ang mga sumusunod na command:
   • ipakita ang mga interface
   • subaybayan ang trapiko ng interface
3. Gumawa ng patakaran para sa pagtanggi sa ruta: 
   • Itakda ang policy-options policy-statement tapos tanggihan.
4. Kung naka-configure ang device sa BGP, bawiin ang lahat ng ina-advertise na ruta ng BGP mula sa lahat ng peer super-spie. Dito, ang grupong SUPER-SPINES ay tumutukoy sa lahat ng super-spine switch na kumikilos bilang BGP peer ng spine switch na ina-upgrade:
   • magtakda ng mga protocol bgp group SUPER-SPINES i-export ang DENY-ALL at mag-commit. Para sa impormasyon sa mga command sa pag-export ng ruta ng BGP, tingnan https://www.juniper.net/documentation/us/en/software/junos/bqp/topics/ref/statement/expor t-edit-protocols-bgp.html
5. Kung naka-configure ang device sa BGP, bawiin ang lahat ng ina-advertise na ruta ng BGP mula sa lahat ng peer na dahon, dito ang LEAF group ay tumutukoy sa mga leaf switch na kumikilos bilang BGP peer ng spine switch na ina-upgrade:
   • magtakda ng mga protocol bgp group LEAF export DENY-ALL at mag-commit.
6. Tandaan ang IP address sa device na naka-configure sa bawat BGP peer switch na nakakonektang interface. Patakbuhin ang sumusunod na command sa device:
   • Ipakita ang mga interface maikli
7. I-verify sa bawat BGP peer switch (parehong super-spine at leaf) na ang mga rutang ini-export ng device ay binawi:
   • ipakita ang buod ng bap
     Mayroong maraming mga entry na ipinapakita. Suriin ang entry na naaayon sa device. Matutukoy ito gamit ang IP address na na-configure sa interface ng device na nakakonekta sa peer switch, kung saan pinapatakbo ang CLI na ito. Sa entry na nauugnay sa device (sa peer switch), ang mga rutang natanggap mula sa device ay dapat ipakita bilang 0/0/0/0 sa ilalim ng column
     Estado|#Active/Natanggap/Tinanggap/Damped.
   • Bilang kahalili, maaari mo ring patakbuhin ang sumusunod na command sa bawat BGP peer switch (parehong super-spine at dahon) ng device:
   • Ipakita ang bgp kapitbahay
     Dapat itong magpakita ng parehong impormasyon sa ilalim ng heading:
     Table inet.
8. Kung ang anumang BGP peer switch ay nagpapadala ng trapiko sa device, subaybayan ang mga istatistika ng trapiko sa peer switch na iyon at maghintay hanggang ang mga incremental na egress stats (mga packet ng output) sa mga konektadong interface ng device nito ay maging halos Kung sakaling mayroong pinagsama-samang ethernet interface sa pagitan ng peer switch at device na ito , tukuyin ang mga constituent interface gamit ang sumusunod na command sa peer switch:
   • ipakita ang mga interface ng lacp Subaybayan ang rate ng paglabas ng trapiko sa mga nakakonektang interface ng device ng peer switch gamit ang sumusunod na command: ipakita ang mga interface
   • subaybayan ang trapiko ng interface

Pre-Upgrade BGP Specific Operations sa Leaf
Gawin ang mga sumusunod na hakbang:

1. Sundin ang hakbang 1 ng pre-upgrade na partikular na operasyon ng BGP sa spine switch.
2. Ang pamamaraan para sa pag-withdraw ng mga na-advertise na ruta ng BGP sa leaf switch na ina-upgrade, ay halos kapareho ng sa spine switch. I-withdraw ang mga na-advertise na ruta sa lahat ng mga spine na kumikilos bilang mga kapantay ng BGP:
   • magtakda ng mga protocol bgp group SPINES i-export ang DENY-ALL at mag-commit.
     Dito, ang SPINES ay tumutukoy sa BGP peer group na naka-configure sa leaf switch para sa peering
     lahat ng mga spines sa pamamagitan ng BGP.
3. Kung sakaling ang TOR switch (o server host) ay konektado sa pamamagitan ng L2 MC-LAG sa device leaf switch, i-disable ang pisikal na interface sa leaf switch na konektado sa TOR switch na iyon (o server host). Ito ay dahil ang TOR switch (o server host) ay maaaring walang eBGP na na-configure at gumagana batay sa L2 na pag-hash ng north-bound na trapiko sa lahat ng leaf switch.
   Samakatuwid, i-disable ang interface sa device leaf switch na ina-upgrade, patungo sa TOR switch (o server host). Pinipigilan nito ang TOR switch (o server host) mula sa pagpapadala ng anumang trapiko sa device leaf switch na ina-upgrade. o itakda ang mga interface na huwag paganahin at i-commit.
4. Sundin ang mga hakbang 5 hanggang 7 sa kaso ng pre-upgrade na mga operasyon ng BGP sa mga spine.

Pre-Upgrade BGP Specific Operations sa Super-Spines
Gawin ang mga sumusunod na hakbang:

1. Sundin ang hakbang 1 ng pre-upgrade na partikular na operasyon ng BGP sa spine switch.
2. Ang pamamaraan para sa pag-withdraw ng mga na-advertise na ruta ng BGP sa super-spine switch na ina-upgrade, ay katulad ng sa leaf switch. I-withdraw ang mga na-advertise na ruta sa lahat ng mga spine na kumikilos bilang mga kapantay ng BGP:
3. magtakda ng mga protocol bgp group SPINES i-export ang DENY-ALL at mag-commit.
   Dito, ang SPINES ay tumutukoy sa BGP peer group na naka-configure sa super-spine switch para sa peering kasama ang lahat ng mga spine sa pamamagitan ng BGP. Sundin ang mga hakbang 5 hanggang 7 sa kaso ng pre-upgrade na mga operasyon ng BGP sa mga spine.

I-upgrade ang Device gamit ang Bagong Larawan at I-reboot
Mayroong iba't ibang mga paraan para sa pag-upgrade ng switch gamit ang bagong larawan:

• CLI based upgrade
• ZTP
• ISSU
• NSSU
  Ang mga detalyadong paglalarawan ay makukuha sa seksyon, Mga Detalye ng Manu-manong Pag-upgrade para sa Mga Switch na Walang Juniper Apstra.

Post-Upgrade Routines Karaniwan sa Single RE at Dual RE Switches At Lahat ng Switch Role

1. Gawin ang mga sumusunod na hakbang:
   Maghintay at i-verify na naka-up ang device.
2.  I-verify na walang mga core ng proseso.
   • paano system core-dumps
3. I-verify na walang karagdagang system at chassis alarm.
   • ipakita ang mga chassis alarm | wala na
   • ipakita ang mga alarma ng system | wala na

Post-Upgrade BGP Specific Operations sa Spine
Gawin ang mga sumusunod na hakbang:

1. I-restart ang mga ruta ng advertising sa lahat ng peer spine. Dito, ang grupong SUPER-SPINES ay tumutukoy sa mga superspine switch na kumikilos bilang mga BGP peer ng spine switch na ina-upgrade:
   • tanggalin ang mga protocol bgp group na SUPER-SPINES i-export ang DENY-ALL at mag-commit.
2. I-restart ang mga ruta ng advertising sa lahat ng peer dahon. Dito, ang LEAF group ay tumutukoy sa mga leaf switch na kumikilos bilang BGP peer ng spine switch na ina-upgrade: o tanggalin ang mga protocol bgp group LEAF export DENY-ALL at i-commit.
3. Kung sakaling maipadala ang trapiko mula sa anumang spine (nagsisilbing BGP peer switch) patungo sa device, subaybayan ang mga istatistika ng trapiko sa peer switch na iyon at maghintay hanggang ang incremental na mga istatistika ng paglabas (mga packet ng output) sa mga nakakonektang interface ng device nito ay maging halos pre-upgrade na halaga. Kung sakaling mayroong pinagsama-samang interface ng ethernet, sa pagitan ng peer switch at device na ito, tukuyin ang bumubuo ng mga pisikal na interface gamit ang CLI na ito sa peer switch:
   • ipakita ang mga interface ng lacp
     Subaybayan ang egress traffic rate sa mga pisikal na interface ng peer switch na konektado sa spine
   • switch na ina-upgrade gamit ang mga sumusunod na CLI: ipakita ang mga interface | grep rate
   • subaybayan ang trapiko ng interface

Post-Upgrade BGP Specific Operations sa Leaf at ToR Switch / Server Host 

1. Gawin ang mga sumusunod na hakbang: 1. I-restart ang pag-advertise ng mga ruta ng BGP sa leaf switch na ina-upgrade. Ang hakbang na ito ay katulad ng sa spine switch. I-restart ang mga ruta ng pag-advertise sa lahat ng spines na kumikilos bilang mga BGP peer: o tanggalin ang mga protocol bgp group SPINES export DENY-ALL at i-commit. Dito, ang SPINES ay tumutukoy sa BGP peer group na naka-configure sa leaf switch para sa peering kasama ang lahat ng mga spine sa pamamagitan ng BGP.
2. Kung sakaling ang TOR switch (o server host) ay konektado sa mga leaf switch sa pamamagitan ng L2 MC-LAG, ang pisikal na interface sa leaf switch na konektado sa TOR switch (o server host), ay kailangang muling paganahin (kung ito ay hindi pinagana nang mas maaga ). Pinapagana nitong muli ang TOR switch (o server host) na ipadala ang trapiko sa lahat ng leaf switch (kabilang ang leaf switch na ina-upgrade) pagkatapos ng L2-hashing.
   • itakda ang mga interface na paganahin at i-commit.
3. Sundin ang hakbang 3 sa kaso ng post-upgrade na mga operasyon ng BGP sa mga spine

Post-Upgrade BGP Specific Operations sa Super-Spines
Gawin ang mga sumusunod na hakbang:

1. I-restart ang pag-advertise ng mga ruta ng BGP sa super-spine switch na ina-upgrade. Ang hakbang na ito ay katulad ng sa spine switch. I-restart ang mga ruta ng advertising sa lahat ng mga spine na kumikilos bilang mga kapantay ng BGP:
   • tanggalin ang mga protocol bgp group SPINES i-export ang DENY-ALL at mag-commit.
     Dito, ang SPINES ay tumutukoy sa BGP peer group na naka-configure sa super-spine switch para sa
     peering sa lahat ng mga spines sa pamamagitan ng BGP. Sundin ang hakbang 3 sa kaso ng post-upgrade na mga operasyon ng BGP
     sa mga gulugod.
2. Sundin ang hakbang 3 sa kaso ng post-upgrade na mga operasyon ng BGP sa mga spine.

I-verify ang Lahat ng Network Core-Facing Interface
Gawin ang mga sumusunod na hakbang:

1. Maghintay at i-verify na ang lahat ng underlay na pagruruta ay tapos na.
2. Maghintay at i-verify na ang mga relasyon sa kapitbahay ng BGP ay naitatag. Hintaying matapos ang pag-update ng ruta ng BGP.
   a) "ipakita ang buod ng bgp" at suriin ang Established status para sa lahat ng mga kapitbahay.
3. Maghintay at i-verify na ang mga interface ng IRB ay pataas. Nalalapat lamang ito kung ang mga interface ng IRB ay na-configure, kadalasang nangyayari ito sa mga switch ng ToR o CE.
   a) ipakita ang mga interface irb

I-verify ang lahat ng End-Device Facing Access Interfaces
Maghintay at i-verify na ang lahat ng trapiko ng user ay naipagpatuloy bilang normal.

Post-Upgrade Health Check
Ulitin ang pamamaraan ng pagsusuri sa kalusugan na isinagawa bago ang pag-upgrade. Maaari itong sundan ng anumang na-customize na mga tseke.

Paglilinis Pagkatapos ng Pag-upgrade

1. Tanggalin ang bagong naka-install na imahe kung kinakailangan.
2. Ibalik ang setting ng configuration ng syslog pabalik sa orihinal.

Mga Sinusuportahang Platform para sa Manu-manong Pamamaraan sa Pag-upgrade (Walang Juniper Apstra)

Talahanayan 2 nagbibigay ng mga detalye ng mga sinusuportahang platform.
Talahanayan 2 Manu-manong Pamamaraan sa Pag-upgrade

Paraan ng Pag-upgrade	Sinusuportahang Sanggunian sa Platform
ISSU	https://apps.juniper.net/feature-explorer/issu.html
NSSU	https://apps.juniper.net/feature-explorer/feature- info.html?fKey=1175&fn=Nonstop+software+upgrade+%28NSSU%29
ZTP	https://apps.juniper.net/feature-explorer/parent-feature- info.html?pFKey=1272&pFName=Zero+Touch+Provisioning

Mga Detalye ng Manu-manong Pag-upgrade para sa Mga Switch na Walang Juniper Apstra

Parehong Single at Dual RE Switch
Ang normal na pag-upgrade na nakabatay sa CLI ay maaaring gamitin para sa parehong single at dual RE switch. Ito ang pinakasimpleng opsyon sa pag-upgrade at kulang sa mga feature na sinusuportahan ng iba pang opsyon. Una, ftp ang bagong software package sa /var/tmp directory sa device. Susunod, patakbuhin ang sumusunod na command:
root@host> humiling ng software ng system na magdagdag ng reboot

Mga Single RE Switch Lamang
Nire-restore ng Zero Touch Provisioning (ZTP) ang switch sa factory default na configuration. Sa ZTP, dapat na muling ilapat ang umiiral nang configuration sa pamamagitan ng a file server kung saan naka-store ang Junos OS Evolved o Junos OS image, dahil mawawala ito. Tandaan na ang switch na ina-upgrade pagkatapos ng ZTP ay dapat
ay konektado sa configuration server / image server sa lahat ng pagkakataon, para mailapat muli ang dati nang configuration pagkatapos ng ZTP.

Mga pagpapalagay
Gumagamit ang device ng impormasyon na naka-configure sa isang Dynamic Host Configuration Protocol (DHCP) server upang mahanap ang kinakailangang imahe at configuration ng software. files sa network. Kung ang DHCP server ay hindi naka-configure upang ibigay ang impormasyong ito, ang naka-preinstall na software at default na factory configuration ay na-load.

Ipinapalagay ng dokumentong ito na ang dhcpd, vsftpd, tftpd, at httpd ay naka-install at naka-configure upang suportahan ang ZTP. Ang device na nakalaan para sa pag-download ng larawan at configuration files ay gumagamit ng isa sa vsftpd, httpd, at tftpd. Ang DHCP ay ginagamit upang magbigay ng mga opsyon para sa ZTP.

DHCP Relay 

Kung ang ZTP server at ang device na ia-upgrade ay hindi direktang konektado sa parehong LAN, kailangan ng DHCP relay. Dapat na pinagana ang relay sa anumang device na nagbibigay ng koneksyon sa pagitan ng device na ina-upgrade at ng ZTP server gamit ang mga sumusunod na CLI:
Itakda ang forwarding-options dhcp-relay server-group test
Itakda ang forwarding-options dhcp-relay active-server-group test Itakda ang forwarding-options dhcp-relay group lahat ng interface
Para sa higit pang impormasyon sa pag-configure ng DHCP relay sa isang Junos OS device, tingnan ang mga sumusunod na dokumento:

• • https://www.juniper.net/documentation/us/en/software/junos/dhcp/topics/topic- map/dhcp-relay-agent-security-devices.html
  • https://www.juniper.net/documentation/us/en/software/junos/dhcp/topics/topic- map/dhcpv6-relay-agent.html
  • https://www.juniper.net/documentation/en_US/junos/topics/topic-map/dhcpv6-relay-agent-switching-devices.html

Pag-set Up ng DHCP Server at Transport Mode

Gawin ang mga sumusunod na hakbang:

1. Sumangguni sa https://linux.die.net/man/5/dhcpd.conf upang malaman ang higit pa tungkol sa mga parameter at sa ibaba ay bilangampang config ng /etc/dhcp/dhcpd.conf.
   • # interface kung saan nakikinig ang dhcp server sa dhcp tumuklas ng mga mensahe.
     DHCPDARGS=ens33;
     # Ang deklarasyon sa ibaba ay ginagamit upang matukoy ang mga subnet kung saan
     para makinig
     # para sa dhcp tumuklas ng mga mensahe at magbigay ng mga ip address.
     # range : tumutukoy kung gaano karaming mga ip address ang lease.
     # domain-name : ay ginagamit upang matukoy ang network, domain nameservers: ginamit
     # kapag ginamit ang mga pangalan ng host sa halip na mga ip address.
     subnet 3.3.3.0 netmask 255.255.255.0 {
     saklaw 3.3.3.3 3.3.3.15;
     opsyon domain-name "mydomain.net";
     opsyon domain-name-servers 10.209.194.133;
     opsyon na mga router 3.3.3.254;
     default-lease-time 60000;
     max-lease-time 720000;
     }
     # Ang deklarasyon sa ibaba ay nagbibigay ng opsyon na kahulugan ng espasyo.
     opsyon space SUNW;
     opsyon SUNW.server-image code 0 = text;
     opsyon SUNW.server-file code 1 = teksto;
     opsyon SUNW.image-file-type code 2 = teksto;
     opsyon SUNW.transfer-mode code 3 = text;
     opsyon SUNW.symlink-server-image code 4 = text;
     opsyon SUNW.http-port code 5 = text;
     opsyon SUNW-encapsulation code 43 = encapsulate SUNW;
     # pangkat ang ginagamit para maglapat ng mga karaniwang parameter para sa isang grupo ng iba't ibang host.
     # pagtukoy sa isang partikular na host at mga parameter nito.
     # "hardware ethernet " mac-address ng device. Para sa MX10003 gagawin nito
     # magkaroon ng mac address ng fxp0 interface.
     # "transfer-mode " mode na ginagamit para sa pag-download ng imahe at config
     # files. Kung wala ito, ang default ay tftp. Ang mga opsyon ay http, ftp at tftp.
     Ang # log-server at ntp-server ay para sa pagpapadala ng mga mensahe ng syslog.
     Ang # "server-image " ay ang imahe para sa device.
     # "server-file ” ay ang opsyon para sa config file.
     Ang # "tftp-server-name" ay ang ip address ng server na nagbibigay ng files
     # para sa pag-boot. Ito ay ibinigay bilang isang string.
     pangkat {
     susunod na server 3.3.3.1;
     host mx204-12345 {
     hardware ethernet 98:a4:04:7f:1a:83;
     opsyon SUNW.transfer-mode “ftp”;
     opsyon host-name "mx204-12345";
     opsyon log-servers 3.3.3.1;
     opsyon ntp-servers 66.129.255.62;
     opsyon SUNW.server-file "dut-baseline-config.conf";
     opsyon SUNW.server-image “junos-vmhost-install-mx-x86-64-
     19.4R1.1.tgz”;
     opsyon tftp-server-name "3.3.3.1";
     Sumunod sa format ng teksto o numero tulad ng nabanggit sa itaas. Kung hindi, ang dhcpd ay nagpapahiwatig ng isang error sa pagsisimula. I-save ang config file at simulan ang serbisyo ng dhcpd. Ang mga log na nauukol sa dhcpd ay maaaring viewed sa /var/log/message file.
2. Kopyahin ang larawan at configuration file sa naaangkop na mga landas depende sa transport mode na na-configure. Ang talahanayan sa ibaba ay isang example assuming /tftpboot/ ay ginagamit ng tftp at ftp para sa file tindahan. Ang server-file at mga pagpipilian sa imahe ng server sa dhcpd.conf file kailangang i-configure ang path na nauugnay sa path para sa transport mode.
   

   Mode ng Transportasyon	Config File Daan	Direktoryo ng Tahanan
   ftp	/etc/vsftpd/vsftpd.conf	/tftpboot
   tftp	/etc/xinet.d/tftp	/tftpboot
   http	/etc/http/conf/httpd.conf	/ var / www / html /

   Para kay example, kung ang imahe ay nasa /tftpboot/PLATFORM_AA/image_aa.tgz, pagkatapos ay ang
   Ang opsyon sa server-image ay dapat na /PLATFORM_AA/image_aa.tgz.
3. Kung ang isang factory default na device ay ibinibigay, gawin ang mga koneksyon sa network at i-on ang device. Kapag nag-boot ang device, magsisimula ang auto image upgrade (AIU).
4. Kung ibibigay ang isang umiiral nang device, pinakamahusay na i-zeroize ang device gamit ang command na "request system zeroize". I-type ang "oo" para sa prompt at pindutin ang Enter.
   Ang aparato ay naka-zero at pagkatapos ay i-reboot. Lumalabas ang device sa amnesiac mode. Mag-login gamit ang root at walang password prompt. Pagkatapos ng ilang minuto, may mga mensahe sa console na nagsasaad na nagsimula na ang ZTP. Mag-isyu ng "ipakita ang dhcp client binding" CLI command para i-verify ang DHCP bound IP.

Pagsubaybay sa Pag-unlad ng ZTP 

Gawin ang mga sumusunod na hakbang:

1. Ang mga sumusunod na mensahe ay nagpapahiwatig ng mga opsyon na ipinadala ng DHCP server:
   Auto Image Upgrade: DHCP INET Options para sa client interface fxp0.0 ConfigFile:
   baseline_mt-bona na LarawanFile: junos-vmhost-install-mx-x86-64- 20.3R1.3.tgz
   Gateway: 17.17.34.1 DHCP Server: 17.17.34.1 File Server: 17.17.34.1
   Pagkatapos, gumagamit ang AIU ng impormasyon sa mga opsyon sa DHCP para i-download ang imahe at configuration files. Ang imahe ay pagkatapos ay naka-install. Pagkatapos ng hakbang sa pag-install ng larawan, nagko-configure ang AIU ng opsyon sa kaganapan para ilapat ang configuration mula sa na-download na configuration file. Bilang huling hakbang pagkatapos ma-install ang bagong larawan, ilapat ang configuration.
   Nasa ibaba ang isang snapshot ng mga mensahe na ipinapakita sa console pagkatapos matanggap ang mga opsyon sa DHCP.
   natatanggap ang mga ption.
   Awtomatikong Pag-upgrade ng Imahe: Para huminto, sa CLI ilapat
   "tanggalin ang chassis auto-image-upgrade" at mag-commit
   Auto Image Upgrade: Aktibo sa INET client interface : fxp0.0
   Awtomatikong Pag-upgrade ng Larawan: Interface:: “fxp0”
   Awtomatikong Pag-upgrade ng Larawan: Server:: “17.17.34.1”
   Awtomatikong Pag-upgrade ng Larawan: Larawan File:: “junos-vmhost-install-mx-x86-64-
   20.3R1.3.tgz”
   Awtomatikong Pag-upgrade ng Larawan: Config File:: “baseline_mt-bona”
   Awtomatikong Pag-upgrade ng Larawan: Gateway:: “17.17.34.1”
   Awtomatikong Pag-upgrade ng Larawan: Protocol:: “ftp”
   Awtomatikong Pag-upgrade ng Larawan: Itinakda sa 300 segundo ang timeout ng FTP
   Ang mga sumusunod ay ang mga mensaheng ipinapakita kapag na-download at na-install ang larawan:
   Auto Image Upgrade: Simulan ang pagkuha ng baseline_mt-bona file mula sa server
   17.17.34.1 hanggang fxp0 gamit ang ftp
   Awtomatikong Pag-upgrade ng Larawan: File baseline_mt-bona na kinuha mula sa server
   17.17.34.1 hanggang fxp0
   Awtomatikong Pag-upgrade ng Larawan: Itinakda sa 300 segundo ang timeout ng FTP
   Auto Image Upgrade: Simulan ang pagkuha ng junos-vmhost-install-mx-x86-64-
   20.3R1.3.tgz file mula sa server 17.17.34.1 hanggang fxp0 gamit ang ftp
   Awtomatikong Pag-upgrade ng Larawan: File junos-vmhost-install-mx-x86-64-20.3R1.3.tgz
   kinuha mula sa server 17.17.34.1 sa pamamagitan ng fxp0
   Awtomatikong Pag-upgrade ng Imahe: Ipinaabort ang pag-install ng larawan ng junos-vmhostinstall-mx-x86-64-20.3R1.3.tgz na natanggap mula 17.17.34.1 hanggang
   fxp0: Parehong bersyon ng na-install at nakuhang larawan
   Auto Image Upgrade: Paglalapat ng baseline_mt-bona file pagsasaayos
   kinuha mula sa server 17.17.34.1 sa pamamagitan ng fxp0
   Ang mga sumusunod ay mga mensahe mula sa /var/log/message file na nagpapakita ng IP address na inilalaan sa device
   Set 26 04:11:41 mx-phs-server1 dhcpd: DHCPREQUEST para sa 17.17.34.110
   mula sa e4:fc:82:0f:d2:00 (TC3718210039) sa pamamagitan ng eth1
   Set 26 04:11:42 mx-phs-server1 dhcpd: DHCPACK noong 17.17.34.110 hanggang
   e4:fc:82:0f:d2:00 (TC3718210039) via eth1
   Set 26 05:11:41 mx-phs-server1 dhcpd: Vendor-Class-Identifier:
   Juniper:ex4600-40f:TC3718210039
   Set 26 05:11:42 mx-phs-server1 dhcpd: DHCPREQUEST para sa 17.17.34.110
   mula sa e4:fc:82:0f:d2:00 (TC3718210039) sa pamamagitan ng eth1
   Set 26 05:11:42 mx-phs-server1 dhcpd: DHCPACK noong 17.17.34.110 hanggang
   e4:fc:82:0f:d2:00 (TC3718210039) via eth1
   Bilang huling hakbang pagkatapos ma-install ang larawan, ilapat ang configuration. Patakbuhin ang "ipakita ang commit ng system" upang i-verify ang output. Dapat may kasamang wastong configuration ang device sa dulo. Para sa mga detalyadong log ng pag-install, maaari mong suriin ang /var/log/image_load_log file.

Pagpapatunay

Upang i-verify na nakatanggap ang device ng IP address mula sa DHCP server, patakbuhin ang sumusunod na command: root@host> ipakita ang dhcp client binding
Sa output, ang estado ng DHCP ay dapat magpakita ng "BOUND".
root@host>ipakita ang log image_load_log
Ipinapakita ng output ang progreso ng proseso ng paglo-load ng imahe ng ZTP.

Pag-troubleshoot

Gawin ang mga sumusunod na hakbang:

1. Tiyaking gumagana ang mga koneksyon. Dahil ang DHCP discover na mga mensahe ay nai-broadcast, ang network ay dapat na ipasa ang mga DHCP discover na mensahe sa DHCP server.
2. Ang katayuan ng proseso ng dhcpd ay dapat tumatakbo o aktibo. Kung hindi, suriin ang /var/log/message file upang i-verify ang isyu. Gamitin ang pareho file upang maghanap ng mga entry sa DHCP
   upang i-verify kung ang DHCP ay nakatuklas ng mga mensahe ay nakarating sa DHCP server. Sa puntong ito, ang device ay dapat magtalaga ng IP address.
3. Ang mga mensahe ng DHCP sa /var/log/messages ay dapat na tumutukoy sa mac-address ng fxp0/em0 interface. Kung wala ito, pagkatapos ay natuklasan ng DHCP na ang mga mensahe mula sa device ay hindi nakakarating sa server.
4. I-verify na ang fxp0/em0 interface ay tumatanggap ng IP address tulad ng ipinapakita sa command output na "ipakita ang dhcp client binding".
   Bilang karagdagan sa IP address, ang aparato ay dapat makatanggap ng impormasyon tungkol sa imahe file, pagsasaayos file, server IP, at ang transport mode na gagamitin para ibigay ang device.
   Kung ang IP address lamang ang matatanggap nang walang mga opsyon, tiyaking naroroon ang opsyon na "tftp-server-name" o ang "server-name". Kung ang alinman sa dalawang ito ay wala, ang dhcpd ay hindi nagpapadala ng mga karagdagang opsyon. Kung ang mga pagbabago ay ginawa sa alinman sa configuration files, dapat na i-restart ang kaukulang serbisyo para magkabisa ang mga pagbabago.
5. Kung natanggap ang mga opsyon ngunit may mga isyu sa pag-download ng imahe o configuration file, tingnan ang configuration para sa kaukulang serbisyo. Ang sampAng mga configuration at setting ay ipinapakita sa ibaba para sa pag-install ng Centos 6.x.
   Sampiwan ang mga opsyon sa vsftd.conf na pinagana para sa pagsuporta sa ztp.
   anonymous_enable = YES
   local_enable = YES
   local_root=/tftpboot/
   write_enable = YES
   local_umask=022
   anon_upload_enable=OO
   anon_mkdir_write_enable=OO
   dirmessage_enable=OO
   xferlog_enable=OO
   xferlog_std_format=OO
   ascii_upload_enable=OO
   ascii_download_enable=OO
   allow_writeable_chroot=OO
   ls_recurse_enable=OO
   makinig=OO
   pam_service_name=vsftpd
   userlist_enable=NO
   userlist_deny=NO
   tcp_wrappers=OO
   anon_root=/tftpboot/ 

   Sample httpd.conf mga opsyon para sa pagsuporta sa ztp
   ServerRoot “/etc/httpd” Makinig : User daemon Group daemon EnableSendfile on
   Sampiwan ang mga opsyon sa tftp para sa pagsuporta sa ztp in
   /etc/xinetd.d/tftp
   server_args = -s /tftpboot/
   huwag paganahin = n

6. Higit pang mga kamakailang pamamahagi ng Linux (para sa halample, Centos 7 o mas bago) ay may firewalld na tumatakbo sa pamamagitan ng Configure upang payagan ang pag-access para sa mga serbisyong ito.
   Ang karagdagang mga detalye ng pamamaraang ito ay matatagpuan sa https://www.juniper.net/documentation/us/en/software/junos/junos-install- upgrade/topics/topic-map/zero-touch-provision.html

Dual RE Switches Lamang 

Ang pamamaraan ng ZTP ay maaaring gamitin para sa dalawahang RE switch. Mayroong iba pang mga pamamaraan na magagamit para sa dalawahang RE switch din.
NSSU

Ginagamit lang ang ISSU para sa dalawahang RE switch at pinagsasama ang GRES sa NSR. Ang mga pagpapalagay ay ang mga sumusunod:

• • Available ang disk space para sa /var file system sa parehong Routing Engine
  • Ang configuration ay sinusuportahan ng isang pinag-isang ISSU
  • Ang mga PIC ay sinusuportahan ng isang pinag-isang ISSU
  • Naka-enable ang Graceful Routing Engine switchover
  • Ang nonstop na aktibong pagruruta ay pinagana Para sa VC/VCF, ang ISSU ay hindi
    Para sa impormasyon ng ISSU, tingnan https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/topic- mapa/issu-understanding.html.
    Para sa mga kinakailangan upang maisagawa ang ISSU, tingnan https://www.juniper.net/documentation/us/en/software/junos/high- availability/topics/concept/issu-system-requirements.html
    Para sa mga detalyadong tagubilin sa pagsasagawa ng ISSU, tingnan https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/topic- map/issu-performing.html
    Para sa ISSU, sinusuportahan namin ang pag-upgrade mula sa bersyon N hanggang N+3. Para kay exampKung gayon, kung ang kasalukuyang bersyon ng Junos OS ay 19, ang inirerekomendang bersyon ng pag-upgrade ay maximum na 19+3 = 22.

TANDAAN: Ang ilan sa mga legacy na PIC ay hindi sumusuporta sa ISSU. Ang mga PIC na nag-o-offline pagkatapos ng ISSU ay kailangang i-online nang manual.

CHAPTER 5 Juniper Apstra Based Upgrade

I-upgrade ang Switch gamit ang Juniper Apstra Software

Ang pamamaraan para sa pag-drain ng trapiko mula sa isang switch sa pamamagitan ng Apstra ay tinukoy dito: https://www.juniper.net/documentation/us/en/software/apstra4.1/apstra-user- guide/topics/task/device-drain.html.
Ang video para sa parehong ay magagamit sa: https://www.youtube.com/watch?v=cpk-0eZ_L_U.
Para sa pamamaraan ng pag-upgrade ng switch, tingnan https://www.juniper.net/documentation/us/en/software/apstra4.1/apstra-user-guide/topics/topic- map/device-nos-upgrade.html.

KABANATA 6 Junos OS Software Rollback

Rollback Junos OS Software

Gawin ang mga sumusunod na hakbang:

1. Makipag-ugnayan sa suporta sa customer para sa mga alarma at core-dump habang/pagkatapos ng pag-upgrade.
   • Ibigay ang syslog file "mga mensahe" at core files
2. Kung sakaling mabigo ang pag-upgrade ng switch dahil sa ISSU, awtomatikong babalik ang switch sa orihinal nitong Junos OS / Junos OS Evolved image. Sa kaso ng NSSU, posibleng ang ilang switch na kabilang sa VC/VCF ay matagumpay na na-upgrade sa mas bagong Junos OS image, habang ang mga natitirang switch ay hindi. Sa ganitong mga kaso, dapat mong manual na i-rollback ang mga bagong na-upgrade na switch sa orihinal na imahe ng Junos OS sa pamamagitan ng mga sumusunod na command:
   • humiling ng system software rollback
   • humiling ng pag-reboot ng system
     Pagkatapos, maaari kang makipag-ugnayan sa suporta sa customer para sa tulong sa pag-upgrade ng mga switch na nabigo sa proseso ng pag-upgrade.

Nai-publish
2023-05-11

Mga Dokumento / Mga Mapagkukunan

Juniper NETWORKS IP Fabric Upgrade Minimum [pdf] Gabay sa Gumagamit IP Fabric Upgrade Minimum, IP, Fabric Upgrade Minimum, Upgrade Minimum

Mga sanggunian

• User Manual