Adesso alcune buone notizie.
Prima di entrare nella sezione di automazione della rete non è necessario imparare Python per
l'esame CCMA coperto dalla certificazione definitiva Cisco.
Ho preso il CCMA e l'esame associato definito lo stesso giorno.
Ne ho parlato in precedenza all'inizio del corso, ma ho intenzione di riprodurre parti di quel video in
questa sezione solo per ricordare i miei pensieri.
Quando ho sostenuto l'esame, la CCMA ha esaminato i test su argomenti come la formattazione dell'API REST Jason che è
trattata nella sezione relativa all'automazione e alle capacità del programma del progetto.
Quindi, ad esempio, assicurati di sapere come interpretare i dati codificati in Jason.
Assicurati di sapere come descrivere le caratteristiche delle API basate sul riposo, quindi ad esempio quando desidero
ottenere dati da un sondaggio utilizzando un'API REST che si ottiene se voglio eliminare
alcuni dati è una cancellazione ASSICURATI DI CONOSCERE IL Verbi API REST ma non è necessario scrivere codice Python utilizzando
l'API REST.
Non devi imparare a rispondere per l'esame.
Ora in questa sezione ti mostrerò gli script Python.
Ti mostrerò sceneggiature di animali.
Non devi tuttavia impararlo per l'esame CCMA.
Devi imparare questo per l'esame definito e le certificazioni degli sviluppatori.
Ora si consiglia di imparare Python.
Decisamente.
Se sei interessato ad andare avanti nella tua carriera, impara Python impara gli animali.
Ho visto queste cose per molti molti anni.
Anni fa stavo spiegando la separazione tra il piano di controllo e il piano dati.
Puoi vedere questo video su YouTube come esempio fatto molti anni fa.
Questa roba è diventata ormai mainstream.
È importante imparare Python e ragionevole per il mondo reale e per andare avanti nella tua carriera.
Ma per l'esame CCMA non devi imparare gli script Python.
Non devi imparare sceneggiature di animali.
Ora, se sento che questo è cambiato, ora stanno testando la tua capacità di codifica.
Aggiornerò questo video.
Ma al momento, poiché non ho sentito nuovi aggiornamenti, puoi presumere che non devi
imparare il pitone e il codice sensibile per l'esame.
Devi capire i principi.
Quindi, ad esempio, qui si parla di spiegare come l'automazione influisce sulla gestione della rete.
Lascia che ti dica che il mondo sta cambiando con l'automazione di rete nello stesso modo in cui in
passato avevamo access point autonomi e ora sono gestiti tramite un controller.
L'idea qui è che avremo un controller che gestisce molti dispositivi.
Ora, nel primo tipo di implementazione di rete definita da SDM o software, il protocollo utilizzato era a flusso
aperto.
C'è una grande differenza tra il modo in cui il flusso aperto ha fatto le cose e il modo in cui
l'automazione di rete viene eseguita oggi nella forma più pura di flusso aperto.
Gli switch o i dispositivi nella rete diventano stupidi.
Il controller che sarebbe semplicemente un server Ubuntu Linux come esempio controlla i dispositivi nella
rete.
Perdono il cervello.
Pertanto, nella CCMA parlano della separazione del piano di controllo e del piano dati e delle API in
direzione nord e in direzione sud, poiché all'inizio comprendono quanto segue.
Dov'è il cervello?
Dov'è l'intelligenza per la rete nella più pura implementazione a flusso aperto.
Il cervello è stato rimosso dal dispositivo di rete e inserito nel controller.
Se avessimo 100 router o 100 switch in una rete tradizionale, avremmo 100 cervelli per ogni router che ogni switch
si controlla da solo.
Ha un proprio piano dati o un piano di inoltro, è così che cambia il traffico dal voler affrontare
un altro.
Ha il suo piano di controllo.
In altre parole, il suo cervello.
Quando un ciclista che utilizza un SPF riceve un aggiornamento, aggiorna la sua tabella di routing.
Quindi la base di informazioni sull'instradamento dei rub che è una tabella basata su software popolata di
ratti appresi tramite SPF, quindi il cervello sta popolando la tabella di instradamento con solchi.
Quindi la base di informazioni di sfregamento o scrittura è una tabella di scrittura basata su software che viene quindi inserita
nell'hardware o nel piano di inoltro o nel piano dati.
In altre parole, nella base di informazioni Ferb o di spedizione.
In altre parole nell'hardware.
Quindi abbiamo il piano di controllo che è il cervello del dispositivo o SPF sta popolando la base di informazioni di
scrittura.
Il cervello determina dove viene instradato il traffico.
Stesso tipo di idea con spanning tree spanning tree BP che l'utente ha ricevuto.
Il cervello decide ancora una volta quali porte offrono quali porte verranno bloccate.
Quindi la cosa da ricordare è che il dispositivo ha un'intelligenza locale.
Il cervello è sul dispositivo.
Se avessimo 100 router, ognuno di loro avrebbe il proprio cervello cerebrale localizzato sul dispositivo.
Ma nell'esempio di flusso aperto più puro i dispositivi sono diventati stupidi e abbiamo messo il cervello nel controller in
modo che il controller centralizzato del controller fosse il cervello per 100 dispositivi.
È bello in un certo senso perché il controller è un dispositivo centrale che puoi manipolare e quindi
aggiornare l'inoltro di 100 dispositivi.
Offre inoltre al dispositivo centralizzato una maggiore visibilità della rete in modo da poter vedere l'intera
rete anziché lo scrittore solo vedere la propria tabella di scrittura locale e non avere visibilità dell'intera
rete.
Ci sono stati dei vantaggi con questo tipo di modello Oh SPF utilizza l'algoritmo SPF per il primo percorso più
breve.
Molto complesso.
Abbiamo un sistema distribuito che poi converge in qualche modo per decidere quale sia il miglior percorso nella rete.
Molto più facile inserire l'intelligenza in un controller centralizzato ma non ha funzionato perché come attaccante
quale dispositivo attaccherò.
Attaccherò quel dispositivo centralizzato se riesco a eliminare il controller.
Non solo tiro fuori un solo router, tiro fuori 100 scrittori, praticamente posso distruggere la tua
rete semplicemente uccidendo il controller.
Ci sono stati altri problemi perché Okay dispositivo sempre così centralizzato.
Ma per quanto riguarda la ridondanza se questa cosa muore, l'intera rete muore.
Quindi quel tipo di schifo.
Quindi quello che farai è avere più di un controller e ora torni allo scenario di database
distribuito o al problema di sincronizzazione.
Come sincronizzare più database in più controller fisici per avere un singolo controller logico.
Quindi c'erano molti altri problemi con questo modello diventato un incubo.
Cosa succede se i rematori perdono la connettività con il controller centralizzato.
Pensaci.
La Rada ha il suo cervello localizzato in un ambiente di rete tradizionale.
Se perde la connettività con un altro scrittore, questo non è un problema perché ha il suo cervello locale.
Quella strada ha il suo cervello locale.
Ma se metti il cervello nel controller e quindi la strada è allentata, la connettività al
controller perché un collegamento si interrompe improvvisamente cosa fanno i cavalieri.
Non hanno cervello, quindi la rete muore o si spezza.
Quindi molti problemi con l'ambiente a flusso aperto puro.
Hanno poi escogitato questo approccio ibrido in cui avevamo un po 'di intelligenza sui dispositivi, un po' di
intelligenza sul controller in cui il controller poteva ignorare ciò che stava facendo un timone in modo da poter scrivere regole
di flusso aperto per il pilota per scavalcare la rete tradizionale.
Quindi il giro come esempio commuta come esempio farebbe il giro tradizionale o il
cambio tradizionale ma poi potremmo creare regole extra qui dove potrei manipolare il flusso di traffico da un
controller centralizzato.
Ora una delle cose interessanti con il modello di flusso aperto e l'idea di un
controller è che questi dispositivi parlano al controller usando quella che viene chiamata API Southbound, quindi il controller seduto
qui parla ai dispositivi usando l'API Southbound.
Notate come ho la mia mano qui API Northbound è API Southbound.
Pensa solo a sud a nord.
Quindi uno sviluppatore di applicazioni potrebbe scrivere un talk applicazione al controller usando un'API northbound.
In genere questi sarebbero Rest Api saggi.
Questo è molto comune oggi e quindi un protocollo verrebbe utilizzato sull'API southbound in modo che il controller parlasse ai riders
e agli switch usando un qualche tipo di protocollo che potrebbe essere a flusso aperto.
Questa era l'idea originale.
Potrebbe essere un deputato.
Non dimenticare un semplice protocollo di gestione della rete utilizzato da anni dalle stazioni di gestione ai dispositivi
di rete in modo che S&P potesse utilizzare l'API Southbound.
Potremmo usare net conf, potremmo usare resto conf, potremmo usare più altre opzioni per NPR meno BGP.
Fondamentalmente c'erano molti protocolli per CCN HS solo per capire che potremmo usare il resto conf che potremmo
usare il resto api è che in realtà potremmo usare CLIA che potremmo usare come MP.
Ora non è necessario utilizzare le altre API del controller per manipolare i dispositivi.
In genere l'idea era che tu fossi uno sviluppatore di applicazioni che utilizzava uno script Python che scriveva
le regole sul controller che poi lo inviava ai dispositivi.
Il vantaggio di questo era questo concetto di astrazione.
Complesso per scrivere regole sui dispositivi.
Era quello che dicevano.
Molto più facile scrivere cose su un'API di riposo sul controller in modo da scrivere le regole sul controller
usando l'API di riposo, quindi l'applicazione utilizza un linguaggio di programmazione di alto livello come Python.
Easy Rest Api nel controller che utilizza quindi più protocolli fino al flusso aperto dei dispositivi.
Net conf BGP a meno che meno interi gruppi di protocolli strani e meravigliosi fino ai dispositivi che si sviluppano
durante l'applicazione vengano sottratti dai dispositivi di rete.
Questa è l'idea ma potresti eliminare un controller e configurare i dispositivi di rete direttamente usando uno script
Python o uno script animale.
Questo è quello che ti mostrerò nel corso perché in realtà è molto più facile
iniziare.
È molto più facile dire che va bene scriviamo un semplice script Python che aggiorna qualcosa in
senso lato o estrae informazioni dal router o dallo switch.
Puoi imitare questo con attrezzatura fisica in un laboratorio o nel genere 3 o virale o anche se vuoi.
Quindi ti mostrerò alcuni esempi di questo, ma ricorda solo che non devi imparare Python
per l'esame.
Non devi imparare il pitone o la programmazione ragionevole per l'esame, ma per il
mondo reale ti suggerirei di imparare entrambi.
Quindi qui parlano della separazione del piano di controllo da un piano dati.
Basta notare dove si trova il dispositivo locale del cervello.
Ai vecchi tempi il piano di inoltro o il piano dati di controllo era nel dispositivo.
Quindi pensa al piano dati come l'inoltro attraverso l'ASX.
Ho un router.
Il traffico arriva su un'interfaccia e passa a un'altra interfaccia, quindi i dati vengono inviati attraverso
il dispositivo.
È acceso sul piano dati o sul piano di inoltro che risiede ancora nel dispositivo.
In genere viene fatto utilizzando A6 ma il piano di controllo o il cervello in cui risiede.
Oggi vogliamo ancora avere il cervello nel flusso aperto del dispositivo, il cervello è stato rimosso e inserito in
un controller separato.
Non vogliamo farlo.
I dispositivi Cisco non supportavano davvero il flusso aperto.
Ancora no.
L'idea è che il cervello rimanga sul dispositivo ma possiamo usare un controller centralizzato per configurare
i dispositivi.
Quindi, piuttosto che realizzare il dispositivo, consentiamo comunque loro di fare il loro inoltro,
permettendo loro di avere il loro cervello locale, ma possiamo configurare i dispositivi direttamente o tramite un controller
che semplifica la gestione di molti dispositivi.
Quindi questa è una delle idee centrali di una rete basata su controller.
Ora, quello che non ho menzionato, ha la gestione in realtà tre piani di controllo o di
inoltro.
È come dire scrivere un router.
Come viene inoltrato il traffico attraverso il dispositivo.
Ciò rimane sempre sul dispositivo perché desideriamo passare o inoltrare ad alta velocità sul cervello del dispositivo
dove risiede in genere risiede sul dispositivo.
Ma avremmo potuto inserirlo in un controller.
Dov'è la gestione.
Quindi qual è il piano di gestione.
In genere gestiamo un dispositivo Cisco utilizzando una console o da remoto sarebbe una cattiva idea di Telnet e SSA.
Quindi, come possiamo gestire il dispositivo ora come esseri umani userebbero una di quelle interfacce per configurare il
dispositivo, ma per gestire il dispositivo usando un'applicazione che ai vecchi tempi useremmo il protocollo di gestione della rete SMP
semplice è che un MP ha problemi.
Nessuno è un parlamentare che Virgin vorrebbe essere insicuro molto facile da hackerare.
Cattiva idea di utilizzare S&P versione 1 e versione 2.
È un MP versione 3 che supporta la crittografia e l'autenticazione molto meglio, ma è un MP non facile.
L'OED e il modo di estrarre informazioni da un dispositivo sono difficili, quindi la rabbia che è in atto
da alcuni anni è quella di utilizzare nuovamente un'interfaccia di programmazione delle applicazioni API.
Il resto è una delle API più popolari utilizzate ovunque.
Quindi quando passiamo dall'essere un puro ingegnere di rete a fare più programmazione.
I ragazzi del mondo della programmazione sono abituati a riposare api.
Hanno usato di nuovo ovunque nelle applicazioni.
Pertanto, quando desiderano configurare i dispositivi di rete, è logico che tale dispositivo disponga di un'API di riposo, ma sappiate
solo che molti vecchi dispositivi non avranno un'API di riposo.
È necessario utilizzare un moderno dispositivo di rete Cisco per riposare api.
Quindi, solo perché il riposo è bello non significa che tutti i dispositivi supporteranno il riposo.
Quindi negli esempi che ti mostrerò in questo corso che è molto basato sul mio corso
Python originale, ti mostrerò come configurare i dispositivi usando telnet e SSA.
Perché è un modo semplice per iniziare.
Inizia con le basi a CCN un livello, poi vai e fai il tuo esame associato definito.
Consiglio vivamente di fare la certificazione definitiva in modo da ottenere la certificazione definitiva
in modo da poter dimostrare ai datori di lavoro che non sei solo un ingegnere di rete ma capisci anche la programmazione.
Ora, come ho detto, parlo da molto tempo della programmazione.
Ho parlato di flusso aperto più di cinque anni fa.
Quindi l'idea è che questa roba sia stata gorgogliante nel settore, ma ora Cisco l'ha formalizzata.
Quindi la mia raccomandazione è imparare Python e ragionevole imparare le cose per il mondo reale, non per il solitario CCMA per il mondo reale e per
la certificazione definitiva e andare a ottenere la tua certificazione definitiva il più presto possibile in modo
da poter dimostrare ai datori di lavoro che tu non sei solo un ingegnere di rete
ma capisci anche la programmazione.
Temo che, essendo un ingegnere di rete tradizionale senza alcuna comprensione della programmazione, avrai bisogno di
imparare la programmazione se in futuro volevi avere un buon lavoro, sono davvero contento che
Cisco l'abbia fatto, ma hanno messo solo 10 percento dell'esame è automazione e programmazione, quindi la capacità
del programma di automazione il 10 percento dell'esame non è molto grande e usano parole come spiegare e confrontare.
Non usano parole come configurare o risolvere i problemi, quindi questo è un livello molto alto.
Questo è il tipico modo Cisco di farlo ad altissimo livello, ma forse nella prossima versione del CCMA
diventerà più dettagliato e ti verranno chieste ulteriori informazioni.