Guida per l'utente minima per l'aggiornamento di Juniper NETWORKS IP Fabric

Juniper Networks, il logo Juniper Networks, Juniper e Junos sono marchi registrati di Juniper Networks, Inc. negli Stati Uniti e in altri paesi. Tutti gli altri marchi, marchi di servizio, marchi registrati o marchi di servizio registrati sono di proprietà dei rispettivi proprietari.

Juniper Networks non si assume alcuna responsabilità per eventuali inesattezze in questo documento. Juniper Networks si riserva il diritto di cambiare, modificare, trasferire o altrimenti rivedere questa pubblicazione senza preavviso.

Le informazioni in questo documento sono aggiornate alla data sul frontespizio.

AVVISO ANNO 2000
I prodotti hardware e software Juniper Networks sono conformi all'anno 2000. Il sistema operativo Junos non ha limitazioni note legate al tempo fino all'anno 2038.
Tuttavia, è noto che l’applicazione NTP avrà qualche difficoltà nell’anno 2036.

CONTRATTO DI LICENZA PER L'UTENTE FINALE
Il prodotto Juniper Networks oggetto della presente documentazione tecnica è costituito da (o è destinato all'uso con) il software Juniper Networks.
L'uso di tale software è soggetto ai termini e alle condizioni del Contratto di licenza con l'utente finale ("EULA") pubblicato all'indirizzohttps://support.juniper.net/support/eula/. Scaricando, installando o utilizzando tale software, accetti i termini e le condizioni di tale EULA.

CAPITOLO 1 Aggiornamento della struttura IP terminatoview

Informazioni su questa configurazione Esample

Sopraview
Utilizzare questa configurazione di rete, ad esample (NCE) per aggiornare tutti gli switch in un'architettura IP Fabric già installata e funzionante.
Feedback sulla documentazione

Ti invitiamo a fornire feedback in modo da poter migliorare la nostra documentazione.
Invia i tuoi commenti a design-center-comments@juniper.net. Includere il nome del documento o dell'argomento, URL o numero di pagina e versione del software (se applicabile).

CAPITOLO 2 Pianificazione dell'aggiornamento per gli switch in un'architettura IP Fabric

Pianificazione dell'aggiornamento

In questa sezione vengono illustrate le linee guida per la pianificazione dell'aggiornamento.
Aggiorna sempre un dispositivo alla volta nella fase iniziale. Dopo alcuni aggiornamenti riusciti e dopo aver acquisito familiarità con la procedura, è possibile aggiornare gli switch in batch, con più switch foglia alla volta, per distribuzioni su larga scala. Si consiglia di aggiornare gli scambi spine e super spine uno alla volta, per evitare qualsiasi interruzione del traffico nel caso in cui non siano presenti percorsi ridondanti.

Controlla l'attuale utilizzo della larghezza di banda di tutti i collegamenti di rete.
È possibile utilizzare procedure di aggiornamento sia in banda che fuori banda. Se anche un singolo switch nella struttura IP utilizza aggiornamenti basati su ZTP tramite procedura in banda, il relè DHCP deve essere configurato su tutti gli switch nella struttura IP. Questo per garantire che lo switch da aggiornare abbia accesso continuo al server DHCP per il download dell'immagine del software e della configurazione dello switch. Se tutti gli switch nell'IP Fabric vengono aggiornati tramite ISSU/NSSU, non è necessario configurare l'inoltro DHCP su nessuno switch nell'IP Fabric per la procedura in banda.

Vengono utilizzati alcuni comandi show della CLI e vengono raccolte informazioni. Si consiglia di automatizzare i comandi CLI negli script e memorizzare tutte le informazioni sul server. Utilizza gli strumenti per cercare e confrontare rapidamente i dettagli con le informazioni raccolte.
Identificare e progettare alcuni flussi di traffico in grado di convalidare la connettività di rete e che possano essere eseguiti in background durante l'aggiornamento. Ping e traceroute sono comunemente usati a questo scopo.

Pianificare un tempo sufficiente per la finestra di manutenzione (MW). Potrebbero essere necessari più MW per una distribuzione di grandi dimensioni. Aggiorna sempre un dispositivo alla volta nella fase iniziale. Dopo alcuni aggiornamenti riusciti e dopo aver acquisito familiarità con la procedura, l'aggiornamento può essere eseguito in batch con più interruttori foglia alla volta per una distribuzione su larga scala.
Pianifica il cambiamento con tutti i team e gli individui interessati dal cambiamento.

Questo documento supporta il multi-homing di un host server su diversi top-of-rack (TOR) o switch foglia utilizzando la connessione LAG basata su LACP.

CAPITOLO 3 Architetture di distribuzione

DC IP Routed Fabric 5 Stage Clos con Super Spine

Questa architettura include DC IP Routed Fabric 5 Stage Clos con Super Spine con eBGP come protocollo tessuto con ogni strato in AS diverso.
Figura 1: Topologia della struttura IP con protocollo Fabric EBGP, con ogni livello in AS diversi
Tessuto tracciato con architettura Super Spine
Piattaforme supportate
Tabella 1 elenca le piattaforme supportate per diversi ruoli in IP Fabric.
Tabella 1: Piattaforme supportate per IP Fabric

Ruoli del dispositivo	Piattaforme
Foglia/TOR	QFX5130-32CD QFX5220-32CD/128C QFX5120-32C/48Y/48T/48YM QFX5100/QFX5110-48S QFX5200-32C QFX5210-64C ACX7100-48L
Colonna vertebrale	QFX5220-32CD/128C PTX10K8/16

Ruoli del dispositivo	Piattaforme
	QFX5120-32C QFX5210-64C QFX5130-32CD QFX5700 QFX5200-32C PTX10003 QFX5110-32Q
Super Spina dorsale	QFX5220-128C PTX10K8/PTX10K3 QFX5210-64C QFX10K8/16

NOTA: Nelle piattaforme supportate elencate, PTX10K8/16, QFX5700, QFX10K8/16 sono sistemi modulari basati su chassis. Le restanti piattaforme hanno un fattore di forma fisso di dimensioni 1, 2 o 3 unità rack (RU).

Ruoli dei nodi
Nella Figura 1, i seguenti sono i ruoli dei nodi:

P1L1, P1L2, P1L3 e P1L4 sono i nodi foglia in POD-1.

P2L2, P2L2, P2L3 e P2L4 sono i nodi foglia in POD-2.
P1S1, P1S2, P1S3, P1S4 sono i nodi della colonna vertebrale in POD-1.

P2S1, P2S2, P2S3, P2S4 sono i nodi della colonna vertebrale in POD-2.
SS1, SS2, SS3, SS4 sono le super spine nello strato di super spine, comune sia al POD-1 che al POD-2.

Configurazioni degli interruttori

Si prevede che IP Fabric esegua le configurazioni minime di base necessarie per renderlo funzionale. Vedere la Figura 1. Ecco la descrizione minima dei requisiti di configurazione:

La struttura è configurata per dual stack con routing sia IPv4 che IPv6 nella struttura.
Tutti i collegamenti nella struttura sono P2P e configurati sia per IPv4 che per IPv6.
eBGP viene utilizzato come protocollo di routing.
Vengono utilizzati gruppi peer eBGP, tutti gli switch foglia appartengono a 1 gruppo peer eBGP (ad esempio LEAF), tutti gli switch spine appartengono a 1 gruppo peer eBGP (ad esempio SPINE) e tutti gli switch super-spine appartengono a 1 gruppo peer eBGP (ad esempio SUPER-COLORE).
I percorsi potrebbero essere aggregati prima di essere pubblicizzati tramite eBGP.
Il traffico bidirezionale scorre attraverso tutti gli switch nella struttura IP.

CAPITOLO 4 Aggiornamento manuale per switch senza Juniper Apstra

Linee guida per l'aggiornamento livello per livello
A ogni livello, identificare tutte le piattaforme comunemente utilizzate, in modo da poter identificare eventuali eccezioni relative all'aggiornamento per altre piattaforme.

Primo passo: aggiornare i TOR (Edge Switch)
Aggiorna tutti i TOR uno per uno. Si presuppone che tutti i TOR siano singoli dispositivi RE e pertanto il TOR da aggiornare non sia disponibile durante l'aggiornamento per l'inoltro del percorso dati. Nel caso in cui un server sia connesso a un solo TOR in fase di aggiornamento, migrare le VM sui server connessi a TOR non in fase di aggiornamento.

Secondo passaggio: aggiornamento dei dispositivi Leaf
Aggiorna tutti gli interruttori a foglia, uno per uno: foglia1, foglia2, foglia3 e così via. Per gli interruttori RE doppi, utilizzare la procedura ISSU o NSSU.

Terzo passaggio: potenzia le spine
Aggiorna tutti gli interruttori della colonna vertebrale, uno per uno: colonna vertebrale1, colonna vertebrale2, colonna vertebrale3 e così via. Per gli interruttori RE doppi, utilizzare la procedura ISSU o NSSU.

Quarto passo: aggiorna le Super-Spine
Aggiorna tutti gli interruttori super-spine, uno per uno: super-spine1, super-spine2, super-spine3 e così via. Per gli interruttori RE doppi, utilizzare la procedura ISSU o NSSU.

Procedura comune per l'aggiornamento dello switch

Controllo dello stato prima e dopo l'aggiornamento

Si consiglia di verificare lo stato dello switch da aggiornare, sia prima che dopo l'aggiornamento, e di registrare queste informazioni. Le informazioni registrate sul controllo dello stato pre-aggiornamento e post-aggiornamento possono essere confrontate in caso di problemi.

Procedura di controllo dello stato
Eseguire i seguenti passaggi:

Controlla se il flusso di traffico degli utenti è quello previsto, senza alcuna perdita prima e dopo l'aggiornamento.

Effettua il backup delle configurazioni di tutti i dispositivi e salvale su un server prima dell'aggiornamento.
Raccogli informazioni dettagliate e verifica che il sistema sia integro prima e dopo l'aggiornamento.
- Controllare il syslog per eventuali guasti ed errori
- mostra i messaggi di registro | non più
- mostra log chassisd | non più
- Controlla gli allarmi e il core-dump sul sistema
  mostra gli allarmi del telaio | non più
  mostra allarmi di sistema | non più
  mostra i core dump del sistema | non più
- Controlla lo stato RE/FPC/PIC e lo stato delle interfacce (per tutte le piattaforme supportate)
  mostra i dettagli dell'hardware del telaio | non più
  mostra i dettagli del telaio FPC | non più
  mostra lo stato dell'immagine del telaio fpc | non più
  mostra l'ambiente del telaio | non più
  mostra il percorso del motore del telaio | non più
  mostra le descrizioni delle interfacce | abbinare | non più
  mostra le descrizioni delle interfacce | abbinare | non più
  mostra l'interfaccia xe-* | corrisponde a “fisico|tasso” | non più
  mostra interfaccia et-* | corrisponde a “fisico|tasso” | non più
  Sulle piattaforme modulari basate su chassis, è anche possibile eseguire le CLI relative al fabric:
  mostra il riepilogo del tessuto del telaio | non più
  mostra tessuto telaio fpcs | non più
  Per gli switch RE doppi, è necessario verificare la disponibilità allo switchover per ISSU/NSSU:
  a. In caso di doppi switch RE, la RE di backup dovrebbe essere pronta per GRES.
  b. Controllare Master RE: stato pronto "Switchover Ready" eseguendo il comando "richiedi controllo interruttore principale motore-instradamento telaio"
  c. Eseguire il comando "mostra passaggio al sistema" in Backup RE e assicurarsi che sia nello stato pronto.
- Controlla la tabella di routing e la tabella di inoltro, dovrebbero essere come previsto:
  mostra processi di sistema estesi | non più
  mostra la coda krt | non più
  mostra riepilogo percorso | non più
  mostra il riepilogo della tabella di inoltro del percorso | non più
  mostra l'ora di scadenza senza risoluzione arp | non più
  Nella CLI ARP sopra, la mancata risoluzione indica che non vogliamo eseguire ricerche DNS per ogni voce nella tabella ARP. Pertanto, senza risoluzione, vediamo solo gli indirizzi IP, che possono essere più veloci quando si hanno più voci ARP.
- Controllare e archiviare informazioni dettagliate relative alla struttura IP (per tutte le piattaforme supportate):
- mostra il traffico delle statistiche pfe | non più
- mostra la memoria virtuale del sistema | non più
- mostra i dettagli della memoria dell'attività | non più
- mostra la memoria di sistema | non più
- mostra memoria attività | non più
- mostra telaio fpc | non più
- mostra il percorso del motore del telaio | non più
- mostra processi di sistema estesi | non più
- mostra i dettagli della memoria dei processi di sistema | non più
- mostra riepilogo bgp | non più
- mostra le interfacce ae* terse | non più
- mostra le interfacce lacp
- mostra le interfacce delle statistiche lacp
- mostrare le interfacce |non più concise
- mostra sessione bfd | non più
  Sulle piattaforme modulari basate su chassis, è possibile eseguire il comando relativo alla Switch Interface Board (SIB):
  mostra i fratelli del telaio | non più
  Eseguire eventuali controlli personalizzati e procedure di preparazione per il dispositivo di aggiornamento pianificato, dopo aver terminato il controllo dello stato. Tali controlli devono essere eseguiti prima della procedura di aggiornamento elencata nelle sezioni successive del presente documento.

Preparazione per l'aggiornamento

Eseguire i seguenti passaggi:

Controlla lo spazio di archiviazione libero del sistema per garantire spazio di archiviazione sufficiente per la nuova immagine del sistema operativo Junos:
- Esegui "df -k /var/tmp" in modalità shell per controllare lo spazio libero.
- Nel caso in cui lo spazio libero sia inferiore a quello richiesto per l'aggiornamento, possiamo liberare spazio utilizzando il comando elencato nel passaggio 2. Per ZTP, non esiste tale requisito di spazio libero.
Eseguire "richiedi prova di pulizia della memoria di sistema" accanto per controllare l'elenco proposto di files per la cancellazione:

Utilizzare il comando "richiedi pulizia della memoria di sistema" per liberare spazio di archiviazione sui dispositivi se l'elenco proposto di fileda eliminare è accettabile. 3. Cancellare eventuali allarmi e
- core-dump prima dell'aggiornamento: o cancella gli errori di sistema fpc all fpc-slot 4
Copia l'immagine del sistema operativo Junos nella directory /var/tmp del dispositivo. Utilizzare questo passaggio solo se non si utilizza il telefono casa o ZTP.

Operazioni specifiche BGP pre-aggiornamento su Spine
Eseguire i seguenti passaggi:

Si presuppone che ogni switch da aggiornare abbia i seguenti parametri BGP preconfigurati:
- annunci di ritardo-rotta-ritardo minimo-convergenza in entrata
- ritardo-route-advertisements ritardo minimo routing-uptime
  Questo per garantire che i percorsi BGP vengano pubblicizzati da uno switch dopo l'accensione, solo dopo che la convergenza dei percorsi è stata assicurata sullo switch locale. Ciò significa che le rotte nel RIB sono state scaricate nel FIB dello switch. Nel caso in cui le rotte nel RIB non siano disponibili nel FIB, il router locale inizia a pubblicizzare le rotte immediatamente dopo che le rotte sono disponibili nel RIB, anche se il FIB non può inoltrarle. Potrebbe portare a un calo del traffico per le destinazioni i cui percorsi sono stati pubblicizzati dal router locale, ma per le quali non esiste un percorso corrispondente nel FIB del router locale.
  La definizione dei parametri BGP è la seguente:
  convergenza in entrata: specifica un ritardo minimo nell'annuncio del percorso dopo che il peer di origine ha inviato tutti gli aggiornamenti del percorso al router locale in fase di aggiornamento. Il dispositivo locale in fase di aggiornamento attende almeno la durata configurata dopo il completamento della convergenza in entrata nel dispositivo locale per il peer di origine. Per le rotte BGP, il peer di origine invia l'end-of-rib dopo che tutti gli aggiornamenti della rotta sono stati inviati al dispositivo locale. Il valore predefinito è 120 secondi, l'intervallo è compreso tra 1 e 36000 secondi.
  Se tutti i peer BGP del dispositivo sono di tipo IPv4, esegui il comando seguente:
- imposta protocolli famiglia bgp inet unicast annunci di percorso di ritardo ritardo minimo convergenza in entrata
  Se tutti i peer BGP del dispositivo sono di tipo IPv6, esegui il comando seguente:
- imposta protocolli famiglia bgp inet6 pubblicità unicast ritardo percorso ritardo minimo convergenza in entrata
  Se alcuni peer BGP del dispositivo sono di tipo IPv4 e altri sono di tipo IPv6, è necessario impostare la convergenza in entrata sul dispositivo locale in base al peer. Per i peer BGP IPv4, esegui il comando seguente:
- imposta protocolli bgp gruppo neighbor family inet unicast ritardo-routeadvertisements ritardo minimo convergenza in entrata
  Per i peer BGP IPv6, esegui il comando seguente:
- imposta protocolli bgp gruppo famiglia vicina inet6 pubblicità unicast ritardo percorso ritardo minimo convergenza in entrata
  b) Tempo di attività minimo del routing: specificare il ritardo minimo, in secondi, prima dell'invio di un annuncio di percorso dopo l'avvio del processo del protocollo di routing (rpd). Il dispositivo attende almeno la durata configurata prima di inviare annunci di percorso ai suoi peer. Il valore predefinito è 0 secondi, l'intervallo è compreso tra 1 e 36000 secondi.
  Se tutti i peer BGP del dispositivo sono di tipo IPv4, esegui il comando seguente:
- imposta protocolli famiglia bgp inet unicast ritardo-routeadvertisements ritardo minimo routing-uptime
  Se tutti i peer BGP del dispositivo sono di tipo IPv6, esegui il comando seguente:
- imposta protocolli famiglia bgp inet6 unicast ritardo-routeadvertisements ritardo minimo routing-uptime
  Se alcuni peer BGP del dispositivo sono di tipo IPv4 e altri sono di tipo IPv6, il tempo di attività del routing sul dispositivo locale deve essere impostato in base al peer. Per i peer BGP IPv4, esegui il comando seguente:
- imposta protocolli bgp gruppo neighbor family inet unicast ritardo-routeadvertisements ritardo minimo routing-uptime
  Per i peer BGP IPv6, esegui il comando seguente:
- imposta protocolli bgp gruppo neighbor family inet6 unicast ritardo-routeadvertisements ritardo minimo routing-uptime
  Per ulteriori informazioni, vedere, https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/ref/statement/ ritardo-percorso-pubblicità-modifica-protocolli-gruppo-famiglia-unicast.html

Se uno switch peer BGP invia traffico al dispositivo, annotare le statistiche incrementali del traffico in uscita (pacchetti di output) sulle interfacce connesse al dispositivo dello switch. Nel caso in cui sia presente un'interfaccia Ethernet aggregata, tra questo switch peer e il dispositivo, identificare le interfacce fisiche costituenti utilizzando il seguente comando sullo switch peer:
- mostra le interfacce lacp
  Monitorare la velocità del traffico in uscita sulle interfacce fisiche dello switch peer, connesso al dispositivo, utilizzando i seguenti comandi:
- mostra interfacce <nome interfaccia dello switch peer connesso al DUT | tasso di grep
- monitorare il traffico dell'interfaccia
Creare una policy per il rifiuto del percorso:
- Imposta le opzioni-politica istruzione-politica quindi rifiuta.

Se il dispositivo è configurato con BGP, ritira tutti i percorsi BGP pubblicizzati da tutte le superspine peer. Qui, il gruppo SUPER-SPINES si riferisce a tutti gli switch super-spine che agiscono come peer BGP dello switch spine in fase di aggiornamento:
- imposta i protocolli bgp gruppo SUPER-SPINES esporta DENY-ALL e conferma. Per informazioni sui comandi di esportazione della route BGP, vedere https://www.juniper.net/documentation/us/en/software/junos/bqp/topics/ref/statement/expor t-edit-protocols-bgp.html
Se il dispositivo è configurato con BGP, ritira tutti i percorsi BGP pubblicizzati da tutte le foglie peer, qui il gruppo LEAF si riferisce agli switch foglia che agiscono come peer BGP dello switch spine in fase di aggiornamento:
- imposta i protocolli bgp gruppo LEAF esporta DENY-ALL e conferma.
Prendere nota dell'indirizzo IP sul dispositivo configurato su ciascuna interfaccia connessa allo switch peer BGP. Esegui il seguente comando sul dispositivo:
- Mostra interfacce breve

Verificare su ciascun peer switch BGP (sia super-spine che leaf) che i percorsi esportati dal dispositivo vengano ritirati:
- mostra il riepilogo di bap
  Vengono visualizzate più voci. Controlla la voce corrispondente al dispositivo. Questo può essere identificato utilizzando l'indirizzo IP configurato sull'interfaccia del dispositivo connesso allo switch peer, su cui è stata eseguita questa CLI. Nella voce corrispondente al dispositivo (su peer switch), i percorsi ricevuti dal dispositivo dovrebbero essere mostrati come 0/0/0/0 sotto la colonna
  Stato|#Attivo/Ricevuto/Accettato/Damped.
- In alternativa, puoi anche eseguire il seguente comando su ogni switch peer BGP (sia super-spine che leaf) del dispositivo:
- Mostra il vicino bgp
  Questo dovrebbe mostrare le stesse informazioni sotto il titolo:
  Tabella inet.
Se uno switch peer BGP invia traffico al dispositivo, monitorare le statistiche del traffico su quello switch peer e attendere fino a quando le statistiche di uscita incrementali (pacchetti di output) sulle interfacce connesse al dispositivo diventano quasi nel caso in cui sia presente un'interfaccia Ethernet aggregata tra questo switch peer e il dispositivo , identificare le interfacce costituenti utilizzando il seguente comando su peer switch:
- mostra interfacce lacp Monitora la velocità del traffico in uscita sulle interfacce connesse al dispositivo dello switch peer utilizzando il seguente comando: show interfacce <nome dell'interfaccia dello switch peer connesso al DUT | tasso di grep
- monitorare il traffico dell'interfaccia

Operazioni specifiche BGP pre-aggiornamento su Leaf
Eseguire i seguenti passaggi:

Seguire il passaggio 1 dell'operazione specifica BGP pre-aggiornamento sullo switch spine.

La procedura per ritirare i percorsi BGP pubblicizzati sullo switch foglia in fase di aggiornamento è molto simile a quella dello switch spine. Ritira le rotte pubblicizzate a tutte le spine che agiscono come peer BGP:
- imposta i protocolli bgp gruppo SPINES esporta DENY-ALL ed esegui il commit.
  Qui, SPINE si riferisce al gruppo peer BGP configurato sullo switch foglia per il peering
  tutte le spine tramite BGP.
Nel caso in cui uno switch TOR (o host server) sia collegato tramite L2 MC-LAG all'interruttore a foglia del dispositivo, disabilitare l'interfaccia fisica sull'interruttore a foglia collegato a tale switch TOR (o host server). Questo perché lo switch TOR (o l'host del server) potrebbe non avere eBGP configurato e funzionare in base all'hashing L2 del traffico in direzione nord verso tutti gli switch foglia.
Pertanto, disabilitare l'interfaccia sullo switch foglia del dispositivo in fase di aggiornamento, verso lo switch TOR (o l'host del server). Ciò impedisce allo switch TOR (o all'host del server) di inviare traffico allo switch foglia del dispositivo in fase di aggiornamento. o impostare la disabilitazione e il commit delle interfacce.

Seguire i passaggi da 5 a 7 in caso di operazioni BGP pre-aggiornamento sulle spine.

Operazioni specifiche BGP pre-aggiornamento su Super-Spine
Eseguire i seguenti passaggi:

Seguire il passaggio 1 dell'operazione specifica BGP pre-aggiornamento sullo switch spine.

La procedura per ritirare i percorsi BGP pubblicizzati sullo switch super-spine in fase di aggiornamento è simile a quella dello switch foglia. Ritira le rotte pubblicizzate a tutte le spine che agiscono come peer BGP:
imposta i protocolli bgp gruppo SPINES esporta DENY-ALL ed esegui il commit.
Qui, SPINE si riferisce al gruppo peer BGP configurato sullo switch super-spine per il peering con tutte le spine tramite BGP. Seguire i passaggi da 5 a 7 in caso di operazioni BGP pre-aggiornamento sulle spine.

Aggiorna il dispositivo con una nuova immagine e riavvia
Esistono vari metodi per aggiornare uno switch con una nuova immagine:

Aggiornamento basato sulla CLI
ZTP
ISSU

NSSU
Le descrizioni dettagliate sono disponibili nella sezione Dettagli sull'aggiornamento manuale per gli switch senza Juniper Apstra.

Routine post-aggiornamento comuni agli switch RE singoli e doppi e a tutti i ruoli degli switch

Eseguire i seguenti passaggi:
Attendi e verifica che il dispositivo sia attivo.

Verificare che non siano presenti core di processo.
- come viene eseguito il core dump del sistema
Verificare che non siano presenti allarmi aggiuntivi del sistema e del telaio.
- mostra gli allarmi del telaio | non più
- mostra allarmi di sistema | non più

Operazioni specifiche BGP post-aggiornamento su Spine
Eseguire i seguenti passaggi:

Riavviare i percorsi pubblicitari verso tutte le spine peer. Qui, il gruppo SUPER-SPINES si riferisce agli switch superspine che agiscono come peer BGP dello switch spine in fase di aggiornamento:
- elimina i protocolli bgp gruppo SUPER-SPINES esporta DENY-ALL ed esegui il commit.
Riavviare i percorsi pubblicitari verso tutte le foglie peer. In questo caso, il gruppo LEAF si riferisce agli switch foglia che agiscono come peer BGP dello switch spine in fase di aggiornamento: o elimina i protocolli bgp gruppo LEAF esporta DENY-ALL ed effettua il commit.

Nel caso in cui il traffico sia stato inviato da qualsiasi spina (che funge da switch peer BGP) al dispositivo, monitorare le statistiche del traffico su tale switch peer e attendere fino a quando le statistiche incrementali in uscita (pacchetti di output) sulle interfacce connesse al dispositivo diventano quasi un valore pre-aggiornamento. Nel caso in cui sia presente un'interfaccia Ethernet aggregata, tra questo switch peer e il dispositivo, identificare le interfacce fisiche costituenti utilizzando questa CLI sullo switch peer:
- mostra le interfacce lacp
  Monitorare la velocità del traffico in uscita sulle interfacce fisiche dello switch peer collegato alla spina dorsale
- switch in fase di aggiornamento utilizzando le seguenti CLI: mostra interfacce | tasso di grep
- monitorare il traffico dell'interfaccia

Operazioni specifiche BGP post-aggiornamento su switch/host server Leaf e ToR

Eseguire i passaggi seguenti: 1. Riavviare la pubblicità degli instradamenti BGP sullo switch foglia in fase di aggiornamento. Questo passaggio è simile a quello del cambio della colonna vertebrale. Riavviare gli instradamenti pubblicitari a tutte le spine che agiscono come peer BGP: o eliminare i protocolli bgp gruppo SPINE esportare DENY-ALL ed eseguire il commit. Qui, SPINE si riferisce al gruppo peer BGP configurato sull'interruttore a foglia per il peering con tutte le spine tramite BGP.

Nel caso in cui un interruttore TOR (o host server) sia collegato agli interruttori a foglia tramite L2 MC-LAG, l'interfaccia fisica sull'interruttore a foglia collegata allo switch TOR (o host server) deve essere riabilitata (se era stata disabilitata in precedenza ). Ciò riabilita lo switch TOR (o l'host del server) per inviare il traffico a tutti gli switch foglia (incluso lo switch foglia in fase di aggiornamento) dopo l'hashing L2.
- impostare le interfacce abilitate e commit.
Seguire il passaggio 3 in caso di operazioni BGP post-aggiornamento sulle spine

Operazioni specifiche BGP post-aggiornamento su Super-Spine
Eseguire i seguenti passaggi:

Riavviare la pubblicità dei percorsi BGP sullo switch super-spine in fase di aggiornamento. Questo passaggio è simile a quello del cambio della colonna vertebrale. Riavviare i percorsi pubblicitari verso tutte le spine che agiscono come peer BGP:
- elimina i protocolli bgp gruppo SPINES esporta DENY-ALL ed esegui il commit.
  Qui, SPINE si riferisce al gruppo peer BGP configurato sullo switch super-spine per
  peering con tutte le spine tramite BGP. Seguire il passaggio 3 in caso di operazioni BGP post-aggiornamento
  sulle spine.

Seguire il passaggio 3 in caso di operazioni BGP post-aggiornamento sulle spine.

Verifica tutte le interfacce rivolte al core della rete
Eseguire i seguenti passaggi:

Attendere e verificare che tutti i percorsi sottostanti siano attivi.

Attendere e verificare che siano stabilite le relazioni con i vicini BGP. Attendi il completamento dell'aggiornamento del percorso BGP.
a) "mostra riepilogo bgp" e controlla lo stato Stabilito per tutti i vicini.
Attendere e verificare che le interfacce IRB siano attive. Ciò è applicabile solo se le interfacce IRB sono configurate, ciò avviene in genere su switch ToR o CE.
a) mostra le interfacce irb

Verifica tutte le interfacce di accesso rivolte ai dispositivi finali
Attendi e verifica che tutto il traffico degli utenti riprenda normalmente.

Controllo dello stato post-aggiornamento
Ripetere la procedura di controllo dello stato eseguita prima dell'aggiornamento. Può essere seguito da eventuali controlli personalizzati.

Pulizia post-aggiornamento

Elimina l'immagine appena installata, se necessario.
Ripristina l'impostazione della configurazione syslog all'originale.

Piattaforme supportate per le procedure di aggiornamento manuale (senza Juniper Apstra)

Tabella 2 fornisce i dettagli delle piattaforme supportate.
Tabella 2 Procedura di aggiornamento manuale

Metodo di aggiornamento	Riferimento alla piattaforma supportata
ISSU	https://apps.juniper.net/feature-explorer/issu.html
NSSU	https://apps.juniper.net/feature-explorer/feature- info.html?fKey=1175&fn=Nonstop+software+aggiornamento+%28NSSU%29
ZTP	https://apps.juniper.net/feature-explorer/parent-feature- info.html?pFKey=1272&pFName=Zero+Touch+Provisioning

Dettagli sull'aggiornamento manuale per gli switch senza Juniper Apstra

Interruttori RE singoli e doppi
Il normale aggiornamento basato sulla CLI può essere utilizzato sia per switch RE singoli che doppi. Questa è l'opzione di aggiornamento più semplice e non dispone delle funzionalità supportate da altre opzioni. Innanzitutto, eseguire l'ftp del nuovo pacchetto software nella directory /var/tmp sul dispositivo. Successivamente, esegui il seguente comando:
root@host> richiede l'aggiunta del software di sistema riavvia

Solo interruttori RE singoli
Zero Touch Provisioning (ZTP) ripristina il passaggio alla configurazione predefinita di fabbrica. In ZTP la configurazione preesistente deve essere riapplicata tramite a file server in cui è archiviata l'immagine Junos OS Evolved o Junos OS, poiché andrà persa. Si noti che lo switch da aggiornare dopo ZTP deve
essere connesso al server di configurazione/server di immagini in ogni circostanza, in modo che la configurazione preesistente possa essere riapplicata una volta terminato ZTP.

Ipotesi
Il dispositivo utilizza le informazioni configurate su un server DHCP (Dynamic Host Configuration Protocol) per individuare l'immagine e la configurazione del software necessarie files sulla rete. Se il server DHCP non è configurato per fornire queste informazioni, verranno caricati il software preinstallato e la configurazione predefinita di fabbrica.

Questo documento presuppone che dhcpd, vsftpd, tftpd e httpd siano installati e configurati per supportare ZTP. Il dispositivo predisposto per il download dell'immagine e della configurazione files utilizza uno tra vsftpd, httpd e tftpd. DHCP viene utilizzato per fornire opzioni per ZTP.

Relè DHCP

Se il server ZTP e il dispositivo da aggiornare non sono collegati direttamente sulla stessa LAN, è necessario un relè DHCP. Il relè deve essere abilitato su qualsiasi dispositivo che fornisce connettività tra il dispositivo da aggiornare e il server ZTP utilizzando le seguenti CLI:
Imposta opzioni di inoltro DHCP-relay server-group test
Imposta opzioni di inoltro dhcp-relay active-server-group test Imposta opzioni di inoltro dhcp-relay group tutte le interfacce
Per ulteriori informazioni sulla configurazione di un inoltro DHCP su un dispositivo con sistema operativo Junos, consultare i seguenti documenti:

Configurazione del server DHCP e della modalità di trasporto

Eseguire i seguenti passaggi:

Fare riferimento a https://linux.die.net/man/5/dhcpd.conf per saperne di più sui parametri e di seguito è riportato un sample di configurazione di /etc/dhcp/dhcpd.conf.
- # interfaccia su cui è in ascolto il server DHCP A DHCP rileva i messaggi.
  DHCPDARGS=ens33;
  # La dichiarazione seguente viene utilizzata per identificare le sottoreti su cui
  ascoltare
  # per DHCP rileva messaggi e fornisce indirizzi IP.
  # range: specifica quanti indirizzi IP affittare.
  # nome-dominio: viene utilizzato per identificare la rete, server dei nomi di dominio: utilizzato
  # quando vengono utilizzati nomi host anziché indirizzi IP.
  sottorete 3.3.3.0 maschera di rete 255.255.255.0 {
  intervallo 3.3.3.3 3.3.3.15;
  opzione nome dominio “miodominio.net”;
  opzione domain-name-servers 10.209.194.133;
  router opzionali 3.3.3.254;
  tempo di locazione predefinito 60000;
  tempo massimo di locazione 720000;
  }
  # La dichiarazione seguente fornisce una definizione dello spazio delle opzioni.
  spazio opzionale SUNW;
  opzione SUNW.server-image code 0 = testo;
  opzione SUNW.server-file codice 1 = testo;
  opzione SOLE.immagine-file-tipo codice 2 = testo;
  opzione SUNW.transfer-mode codice 3 = testo;
  opzione SUNW.symlink-server-image code 4 = testo;
  opzione SUNW.http-codice porta 5 = testo;
  opzione codice di incapsulamento SUNW 43 = incapsula SUNW;
  # Il gruppo viene utilizzato per applicare parametri comuni per un gruppo di host diversi.
  # definendo un particolare host e i suoi parametri.
  # Indirizzo mac “hardware ethernet” del dispositivo. Per MX10003 lo farà
  # avere l'indirizzo mac dell'interfaccia fxp0.
  # Modalità "modalità trasferimento" utilizzata per scaricare l'immagine e la configurazione
  # fileS. Se assente, il valore predefinito è tftp. Le opzioni sono http, ftp e tftp.
  # log-server e ntp-server servono per inviare messaggi syslog.
  # "server-image" è l'immagine del dispositivo.
  # "server-file " è l'opzione per il file config file.
  # “tftp-server-name” è l'indirizzo IP del server che fornisce il file files
  # per l'avvio. Questo viene fornito come una stringa.
  gruppo {
  prossimo server 3.3.3.1;
  ospite mx204-12345 {
  hardware ethernet 98:a4:04:7f:1a:83;
  opzione SUNW.transfer-mode “ftp”;
  opzione nome host “mx204-12345″;
  opzione log-servers 3.3.3.1;
  opzione ntp-servers 66.129.255.62;
  opzione SUNW.server-file “dut-baseline-config.conf”;
  opzione SUNW.server-image “junos-vmhost-install-mx-x86-64-
  19.4R1.1.tgz”;
  opzione nome-server-tftp “3.3.3.1”;
  Attenersi al formato testo o numero come menzionato sopra. In caso contrario, DHCP indica un errore all'avvio. Salva la configurazione file e avviare il servizio DHCP. I log relativi a DHCP possono essere viewed nel /var/log/messaggi file.
Copia l'immagine e la configurazione file ai percorsi appropriati a seconda della modalità di trasporto configurata. La tabella seguente è un esempioample presupponendo che /tftpboot/ sia utilizzato da tftp e ftp for file negozio. Il server-file e le opzioni dell'immagine del server in dhcpd.conf file è necessario avere il percorso relativo al percorso configurato per la modalità di trasporto.

Modalità di trasporto Configurazione File Sentiero Elenco Home

ftp /etc/vsftpd/vsftpd.conf /tftpboot

tftp /etc/xinet.d/tftp /tftpboot

http /etc/http/conf/httpd.conf / Var / www / html /

Per esempioample, se l'immagine è in /tftpboot/PLATFORM_AA/image_aa.tgz, allora
l'opzione server-image deve essere /PLATFORM_AA/image_aa.tgz.
Se viene effettuato il provisioning di un dispositivo predefinito in fabbrica, effettuare le connessioni di rete e accendere il dispositivo. All'avvio del dispositivo, viene avviato l'aggiornamento automatico dell'immagine (AIU).
Se è necessario effettuare il provisioning di un dispositivo esistente, è meglio azzerare il dispositivo utilizzando il comando "request system zeroize". Digitare "sì" per la richiesta e premere Invio.
Il dispositivo viene azzerato e quindi riavviato. Il dispositivo si presenta in modalità amnesica. Accedi utilizzando root e non viene richiesta la password. Dopo un paio di minuti, sulla console vengono visualizzati dei messaggi che indicano che ZTP è stato avviato. Emettere il comando CLI "mostra associazione client DHCP" per verificare l'IP associato a DHCP.

Monitoraggio dell'avanzamento ZTP

Eseguire i seguenti passaggi:

I seguenti messaggi indicano le opzioni inviate dal server DHCP:
Aggiornamento automatico dell'immagine: opzioni DHCP INET per l'interfaccia client fxp0.0 ConfigurazioneFile:
baseline_mt-bona ImmagineFile: junos-vmhost-install-mx-x86-64- 20.3R1.3.tgz
Gateway: 17.17.34.1 Server DHCP: 17.17.34.1 File Server: 17.17.34.1
Quindi, AIU utilizza le informazioni nelle opzioni DHCP per scaricare l'immagine e la configurazione fileS. L'immagine viene quindi installata. Dopo la fase di installazione dell'immagine, AIU configura un'opzione evento per applicare la configurazione dalla configurazione scaricata file. Come ultimo passaggio dopo l'installazione della nuova immagine, applicare la configurazione.
Di seguito è riportata un'istantanea dei messaggi visualizzati sulla console dopo la ricezione delle opzioni DHCP.
le opzioni vengono ricevute.
Aggiornamento automatico dell'immagine: per interrompere, applicare sulla CLI
"elimina l'aggiornamento automatico dell'immagine dello chassis" ed esegui il commit
Aggiornamento automatico dell'immagine: attivo sull'interfaccia client INET: fxp0.0
Aggiornamento automatico dell'immagine: Interfaccia:: “fxp0”
Aggiornamento automatico immagine: Server:: “17.17.34.1”
Aggiornamento automatico dell'immagine: Immagine File:: “junos-vmhost-install-mx-x86-64-
20.3R1.3.tgz”
Aggiornamento automatico dell'immagine: config File:: “baseline_mt-bona”
Aggiornamento automatico immagine: Gateway:: “17.17.34.1”
Aggiornamento automatico immagine: Protocollo:: “ftp”
Aggiornamento automatico dell'immagine: timeout FTP impostato su 300 secondi
Di seguito sono riportati i messaggi visualizzati quando l'immagine viene scaricata e installata:
Aggiornamento automatico dell'immagine: inizia a recuperare baseline_mt-bona file dal server
17.17.34.1 tramite fxp0 utilizzando ftp
Aggiornamento automatico dell'immagine: File baseline_mt-bona recuperato dal server
17.17.34.1 fino a fxp0
Aggiornamento automatico dell'immagine: timeout FTP impostato su 300 secondi
Aggiornamento automatico dell'immagine: avvia il recupero di junos-vmhost-install-mx-x86-64-
20.3R1.3.tgz file dal server 17.17.34.1 tramite fxp0 utilizzando ftp
Aggiornamento automatico dell'immagine: File junos-vmhost-install-mx-x86-64-20.3R1.3.tgz
recuperato dal server 17.17.34.1 tramite fxp0
Aggiornamento automatico dell'immagine: interruzione dell'installazione dell'immagine di junos-vmhostinstall-mx-x86-64-20.3R1.3.tgz ricevuta dal 17.17.34.1 fino a
fxp0: versione dell'immagine installata e recuperata identica
Aggiornamento automatico dell'immagine: applicazione di baseline_mt-bona file configurazione
recuperato dal server 17.17.34.1 tramite fxp0
Quelli che seguono sono i messaggi del /var/log/messaggi file che mostrano l'indirizzo IP assegnato al dispositivo
26 settembre 04:11:41 mx-phs-server1 dhcpd: DHCPREQUEST per 17.17.34.110
da e4:fc:82:0f:d2:00 (TC3718210039) tramite eth1
26 settembre 04:11:42 mx-phs-server1 dhcpd: DHCPACK il 17.17.34.110 a
e4:fc:82:0f:d2:00 (TC3718210039) via eth1
26 settembre 05:11:41 mx-phs-server1 dhcpd: Identificatore classe fornitore:
Ginepro:ex4600-40f:TC3718210039
26 settembre 05:11:42 mx-phs-server1 dhcpd: DHCPREQUEST per 17.17.34.110
da e4:fc:82:0f:d2:00 (TC3718210039) tramite eth1
26 settembre 05:11:42 mx-phs-server1 dhcpd: DHCPACK il 17.17.34.110 a
e4:fc:82:0f:d2:00 (TC3718210039) via eth1
Come ultimo passaggio dopo l'installazione dell'immagine, applicare la configurazione. Corri il “mostra commit del sistema” per verificare l'output. Alla fine il dispositivo deve includere una configurazione valida. Per i registri di installazione dettagliati, è possibile controllare il file /var/log/image_load_log file.

Verifica

Per verificare che il dispositivo abbia ricevuto l'indirizzo IP dal server DHCP, eseguire il comando seguente: root@host> mostra l'associazione del client DHCP
Nell'output, lo stato DHCP deve visualizzare "BOUND".
root@host>mostra registro image_load_log
L'output mostra l'avanzamento del processo di caricamento dell'immagine ZTP.

Risoluzione dei problemi

Eseguire i seguenti passaggi:

Assicurarsi che le connessioni funzionino. Poiché i messaggi di rilevamento DHCP vengono trasmessi, la rete deve inoltrare questi messaggi di rilevamento DHCP al server DHCP.
Lo stato del processo DHCP deve essere in esecuzione o attivo. In caso contrario, controlla il /var/log/messaggi file per verificare il problema. Usa lo stesso file per cercare le voci DHCP
per verificare se i messaggi di rilevamento DHCP raggiungono il server DHCP. A questo punto al dispositivo dovrebbe essere assegnato un indirizzo IP.
I messaggi DHCP in /var/log/messages dovrebbero riguardare l'indirizzo mac dell'interfaccia fxp0/em0. Se non è presente, i messaggi di rilevamento DHCP provenienti dal dispositivo non raggiungono il server.
Verificare che l'interfaccia fxp0/em0 riceva l'indirizzo IP come mostrato nell'output del comando "mostra associazione client DHCP".
Oltre all'indirizzo IP, il dispositivo deve ricevere informazioni sull'immagine file, configurazione file, IP del server e modalità di trasporto da utilizzare per effettuare il provisioning del dispositivo.
Se viene ricevuto solo l'indirizzo IP senza opzioni, assicurarsi che siano presenti l'opzione "tftp-server-name" o "server-name". Se una di queste due non è presente, dhcpd non invia le opzioni aggiuntive. Se vengono apportate modifiche a una qualsiasi delle configurazioni files, il servizio corrispondente deve essere riavviato affinché le modifiche abbiano effetto.
Se le opzioni vengono ricevute ma si verificano problemi con il download dell'immagine o della configurazione file, controlla la configurazione del servizio corrispondente. Il sampLe configurazioni e le impostazioni dei le sono mostrate di seguito per un'installazione di Centos 6.x.
Sample opzioni vsftd.conf abilitate per il supporto di ztp.
anonymous_enable = SÌ
local_enable = YES
root_locale=/tftpboot/
write_enable = YES
local_umask=022
anon_upload_enable=SI
anon_mkdir_write_enable=SÌ
dirmessage_enable=SÌ
xferlog_enable=SÌ
xferlog_std_format=SÌ
ascii_upload_enable=SÌ
ascii_download_enable=SÌ
consent_writeable_chroot=SÌ
ls_recurse_enable=SÌ
ascolta=SI
pam_service_name=vsftpd
userlist_enable=NO
userlist_deny=NO
tcp_wrappers=SÌ
anon_root=/tftpboot/
Sample opzioni httpd.conf per supportare ztp
ServerRoot “/etc/httpd” Ascolta: demone utente Demone gruppo EnableSendfile on
Sample opzioni tftp per supportare ztp in
/etc/xinetd.d/tftp
argomenti_server = -s /tftpboot/
disabilitare = n
Le distribuzioni Linux più recenti (ad esample, Centos 7 o successivo) dispongono di firewalld eseguito da Configure per consentire l'accesso a questi servizi.
Ulteriori dettagli su questa procedura sono disponibili all'indirizzo https://www.juniper.net/documentation/us/en/software/junos/junos-install- upgrade/topics/topic-map/zero-touch-provision.html

Solo interruttori Dual RE

La procedura ZTP può essere utilizzata per commutatori RE doppi. Sono disponibili anche altre procedure per gli interruttori RE doppi.
NSSU

ISSU viene utilizzato solo per doppi interruttori RE e combina GRES con NSR. Le ipotesi sono le seguenti:

- Lo spazio su disco è disponibile per /var file sistema su entrambi i motori di routing
- La configurazione è supportata da un ISSU unificato
- I PIC sono supportati da un ISSU unificato
- La commutazione del Graceful Routing Engine è abilitata
- Il routing attivo continuo è abilitato Per VC/VCF, ISSU non lo è
  Per le informazioni sull'ISSU, cfr https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/topic- map/issu-understanding.html.
  Per i requisiti per eseguire l'ISSU, vedere https://www.juniper.net/documentation/us/en/software/junos/high- disponibilità/topics/concept/issu-system-requirements.html
  Per le istruzioni dettagliate su come eseguire ISSU, vedere https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/topic- map/issu-performing.html
  Per ISSU, supportiamo l'aggiornamento dalla versione N a N+3. Per esample, se la versione corrente del sistema operativo Junos è 19, la versione di aggiornamento consigliata è al massimo 19+3 = 22.

NOTA: Alcuni dei PIC legacy non supportano ISSU. I PIC che vanno offline dopo l'ISSU devono essere messi online manualmente.

CAPITOLO 5 Aggiornamento basato su Juniper Apstra

Aggiorna lo Switch con il software Juniper Apstra

La procedura per scaricare un traffico da uno switch via Apstra è qui specificata: https://www.juniper.net/documentation/us/en/software/apstra4.1/apstra-user- guide/topics/task/device-drain.html.
Il video dello stesso è disponibile su: https://www.youtube.com/watch?v=cpk-0eZ_L_U.
Per una procedura di aggiornamento dello switch, vedere https://www.juniper.net/documentation/us/en/software/apstra4.1/apstra-user-guide/topics/topic- map/device-nos-upgrade.html.

CAPITOLO 6 Rollback del software del sistema operativo Junos

Rollback del software del sistema operativo Junos

Eseguire i seguenti passaggi:

Contatta l'assistenza clienti per allarmi e core dump durante/dopo l'aggiornamento.
- Fornire il log di sistema file “messaggi” e nucleo files
Nel caso in cui l'aggiornamento dello switch non riesca a causa di ISSU, lo switch torna automaticamente all'immagine Junos OS/Junos OS Evolved originale. Nel caso di NSSU, è possibile che alcuni switch appartenenti a VC/VCF vengano aggiornati con successo alla nuova immagine del sistema operativo Junos, mentre gli switch rimanenti no. In questi casi, è necessario eseguire manualmente il rollback degli switch appena aggiornati all'immagine originale del sistema operativo Junos tramite i seguenti comandi:
- richiedere il rollback del software di sistema
- richiedere il riavvio del sistema
  Quindi, puoi contattare l'assistenza clienti per ricevere assistenza nell'aggiornamento degli switch che non hanno superato il processo di aggiornamento.

Pubblicato
Numero di telefono: 2023-05-11

Documenti / Risorse

Minimo aggiornamento struttura IP Juniper NETWORKS [pdf] Guida utente
Minimo aggiornamento struttura IP, IP, Aggiornamento minimo struttura, Minimo aggiornamento

Riferimenti

Manuale d'uso

Configurazione di rete Esample

CAPITOLO 1 Aggiornamento della struttura IP terminatoview

Informazioni su questa configurazione Esample

CAPITOLO 2 Pianificazione dell'aggiornamento per gli switch in un'architettura IP Fabric

CAPITOLO 3 Architetture di distribuzione

CAPITOLO 4 Aggiornamento manuale per switch senza Juniper Apstra

Procedura comune per l'aggiornamento dello switch

Piattaforme supportate per le procedure di aggiornamento manuale (senza Juniper Apstra)

Dettagli sull'aggiornamento manuale per gli switch senza Juniper Apstra

Risoluzione dei problemi

CAPITOLO 5 Aggiornamento basato su Juniper Apstra

Aggiorna lo Switch con il software Juniper Apstra

CAPITOLO 6 Rollback del software del sistema operativo Junos

Rollback del software del sistema operativo Junos

Documenti / Risorse

Riferimenti

Lascia un commento

Annulla risposta

Modalità di trasporto	Configurazione File Sentiero	Elenco Home
f`tp`	`/etc/vsftpd/vsftpd.conf`	`/tftpboot`
`tftp`	`/etc/xinet.d/tftp`	`/tftpboot`
http	/etc/http/conf/httpd.conf	/ Var / www / html /