Ahora algunas buenas noticias.
Antes de entrar en la sección de automatización de red, no tiene que aprender Python para el examen CCMA
que está cubierto en la certificación definitiva de Cisco.
Tomé el CCMA y el examen definitivo de asociado el mismo día.
He hablado anteriormente sobre esto al principio del curso, pero voy a reproducir partes de ese video
en esta sección solo para recordarles mis pensamientos.
Cuando tomé el examen, el CCMA examinó las pruebas sobre temas como el formato Jason REST API que se
cubre en la sección de automatización y capacidad del programa del plan.
Entonces, como ejemplo, asegúrese de saber cómo interpretar los datos codificados de Jason.
Asegúrese de saber cómo describir las características de las API basadas en reposo, por ejemplo, cuando quiero obtener datos
de una encuesta utilizando una API REST que es un resultado si quiero eliminar algunos datos,
es una eliminación. ASEGÚRESE DE QUE SABE Los verbos de la API REST pero no tienes que escribir código Python usando la
API REST.
No tiene que aprender a responder por el examen.
Ahora, en esta sección, le mostraré los scripts de Python.
Te voy a mostrar guiones de animales.
Sin embargo, no tiene que aprender eso para el examen CCMA.
Debe aprender eso para el examen definitivo y las certificaciones de desarrollador.
Ahora se recomienda que aprendas Python.
Seguro.
Si está interesado en avanzar en su carrera, aprenda Python learn animal.
He estado viendo estas cosas durante muchos años.
Hace años estaba explicando la separación del plano de control y el plano de datos.
Puedes ver este video en YouTube como un ejemplo hecho hace muchos años.
Estas cosas ahora se han convertido en la corriente principal.
Es importante que aprenda Python y que sea sensible para el mundo real y que avance en su carrera.
Pero para el examen CCMA no tiene que aprender scripts de Python.
No tienes que aprender guiones de animales.
Ahora, si escucho que esto ha cambiado, ahora están probando su capacidad de codificación.
Actualizaré este video.
Pero en este momento porque no he escuchado ninguna actualización nueva, puede suponer que no
tiene que aprender python y código sensible para el examen.
Necesitas entender los principios.
Entonces, como ejemplo, hablan de explicar cómo la automatización afecta la gestión de la red.
Permítanme decirles que el mundo está cambiando con la automatización de la red de la misma manera que teníamos puntos
de acceso autónomos en el pasado y ahora se administran utilizando un controlador.
La idea aquí es que vamos a tener un controlador que gestione muchos dispositivos.
Ahora, en el primer tipo de SDM o implementación de red definida por software, el protocolo utilizado era flujo
abierto.
Hay una gran diferencia entre la forma en que el flujo abierto hizo las cosas y la forma en que la automatización de
la red se realiza hoy en la forma más pura de flujo abierto.
Los conmutadores o dispositivos en su red se vuelven tontos.
El controlador que simplemente sería un servidor Linux ubuntu como ejemplo controla los dispositivos en la
red.
Pierden su cerebro.
Entonces, en el CCMA, hablan sobre la separación del plano de control y el plano de datos y las API
hacia el norte y hacia el sur, como principio, entiendan lo siguiente.
¿Dónde está el cerebro?
¿Dónde está la inteligencia para la red en la implementación de flujo abierto más puro?
El cerebro fue retirado del dispositivo de red y puesto en el controlador.
Si teníamos 100 enrutadores o 100 conmutadores en una red tradicional, tenemos 100 cerebros en cada enrutador que
controla cada conmutador.
Tiene su propio plano de datos o plano de reenvío, así es como cambia el tráfico de querer enfrentar
a otro.
Tiene su propio plano de control.
En otras palabras, su propio cerebro.
Cuando un usuario que utiliza un SPF recibe una actualización, actualiza su tabla de enrutamiento.
Entonces, la base de información de enrutamiento de fricción es una tabla basada en software que está poblada con ratas
aprendidas a través de SPF, por lo que el cerebro está poblando la tabla de enrutamiento con surcos.
Entonces, la base de información de escritura o roce es una tabla de escritura basada en software que luego se introduce en el
hardware o en el plano de reenvío o plano de datos.
En otras palabras, en la base de información de Ferb o reenvío.
En otras palabras, en hardware.
Entonces tenemos el plano de control que es el cerebro del dispositivo o SPF está poblando la base de información de
escritura.
El cerebro determina hacia dónde se dirige el tráfico.
El mismo tipo de idea con el árbol de expansión árbol de expansión BP que recibió el usuario.
El cerebro decide una vez más qué puertos que permiten bloquearlos.
Entonces, lo que hay que recordar es que el dispositivo tiene una inteligencia local.
El cerebro está en el dispositivo.
Si tuviéramos 100 enrutadores, cada uno tendría su propio cerebro, el cerebro se localiza en el dispositivo.
Pero en el ejemplo de flujo abierto más puro, los dispositivos se volvieron tontos y pusimos el cerebro en el
controlador para que el controlador centralizado fuera el cerebro de 100 dispositivos.
Eso es bueno porque el controlador es un dispositivo central que puede manipular y luego actualizar
el reenvío de 100 dispositivos.
También le da al dispositivo centralizado más visibilidad de la red para que pueda ver toda la red
en lugar de que el escritor solo vea su propia tabla de escritura local y no tenga visibilidad de toda
la red.
Hubo ventajas con este tipo de modelo. Oh SPF utiliza el algoritmo SPF de la ruta más corta
primero.
Muy complejo.
Tenemos un sistema distribuido que luego de alguna manera converge para decidir cuál es el mejor camino en la red.
Mucho más fácil poner la inteligencia en un controlador centralizado, pero no funcionó porque, como atacante, a qué
dispositivo voy a atacar.
Voy a atacar ese dispositivo centralizado si puedo sacar el controlador.
No solo saco un enrutador, saco 100 escritores, básicamente puedo destruir su red
simplemente matando el controlador.
Hubo otros problemas porque Ok, dispositivo centralizado.
Pero, ¿qué pasa con la redundancia si esta cosa muere, toda su red muere?
Entonces ese tipo de apesta.
Entonces, lo que vas a hacer es tener más de un controlador y ahora vuelves al escenario de la base de
datos distribuida o al problema de sincronización.
¿Cómo sincronizo múltiples bases de datos en múltiples controladores físicos para tener un solo controlador lógico?
Así que hubo muchos otros problemas con este modelo que se convirtió en una pesadilla.
Qué sucede si los alborotadores pierden conectividad con el controlador centralizado.
Piénsalo.
La Rada tiene su propio cerebro localizado en un entorno de red tradicional.
Si pierde la conectividad con otro escritor, eso no es un problema porque tiene su propio cerebro local.
Ese camino tiene su propio cerebro local.
Pero si pones el cerebro en el controlador y luego el camino es una conectividad floja con el
controlador porque un enlace se cae repentinamente, ¿qué hacen los conductores?
No tienen cerebro, por lo que la red muere o se rompe.
Así que muchos problemas con el entorno de flujo abierto puro.
Luego se les ocurrió este enfoque híbrido en el que teníamos algo de inteligencia en los dispositivos, algo
de inteligencia en el controlador, donde el controlador podía anular lo que estaba haciendo un timón para que pudiéramos escribir reglas
de flujo abierto para el conductor para anular las redes tradicionales.
Entonces, el paseo como un cambio de ejemplo como ejemplo haría un viaje tradicional o
un cambio tradicional, pero luego podríamos crear reglas adicionales aquí donde podría manipular el flujo de tráfico desde un
controlador centralizado.
Ahora, una de las cosas interesantes con el modelo de flujo abierto y la idea general de un controlador es que
estos dispositivos hablan con el controlador usando lo que se llama una API hacia el sur, por lo que el controlador está sentado aquí y habla
de los dispositivos que usan la API hacia el sur.
Observe cómo tengo mi mano aquí. La API en dirección norte es la API en dirección sur.
Solo piensa en el sur, el norte, el norte.
Entonces, un desarrollador de aplicaciones podría escribir una charla de aplicación al controlador utilizando una API hacia el norte.
Por lo general, estos serían Rest Api wise.
Eso es muy común hoy y luego se usaría un protocolo en la API hacia el sur para que el controlador hablara
con los pilotos y los interruptores utilizando algún tipo de protocolo que podría ser flujo abierto.
Esa fue la idea original.
Podría ser un diputado.
No olvide que se usó un protocolo simple de administración de red durante años, desde estaciones de administración hasta dispositivos de red,
por lo que S&P podría estar utilizando la API hacia el sur.
Podríamos usar net conf, podríamos usar rest conf, podríamos usar muchas otras opciones para NPR menos BGP.
Básicamente, había muchos protocolos para CCN HS. Simplemente entendimos que podríamos usar rest conf.
Podríamos usar rest api. De hecho, podríamos usar CLIA. Podríamos usarlo como MP.
Ahora no tiene que usar la API del resto del controlador para manipular dispositivos.
Por lo general, la idea era que eras un desarrollador de aplicaciones que usaba un script de Python que escribía
reglas en el controlador que luego lo enviaba a los dispositivos.
La ventaja de esto fue este concepto de abstracción.
Complejo para escribir reglas en dispositivos.
Eso fue lo que dijeron.
Es mucho más fácil escribir cosas en una API de descanso en el controlador para que pueda escribir reglas en el controlador
utilizando la API de descanso para que la aplicación use un lenguaje de programación de alto nivel como Python.
Easy Rest Api en el controlador que luego usa múltiples protocolos hasta el flujo abierto de los dispositivos.
Net conf BGP a menos que se extraigan de los dispositivos de red menos protocolos extraños y maravillosos
para los dispositivos que desarrolla la aplicación.
Esa es la idea, pero podría eliminar un controlador y simplemente configurar los dispositivos de red directamente usando
un script Python o script animal.
Eso es lo que les voy a mostrar en el curso porque es mucho más fácil comenzar
realmente.
Es mucho más fácil decir que está bien, escribamos un script simple de Python que actualice algo en
el más amplio o extraiga información del enrutador o conmutador.
Puede imitar esto con equipo físico en un laboratorio o en el género 3 o viral o incluso si lo desea.
Así que te mostraré algunos ejemplos de eso, pero recuerda que no tienes que aprender Python
para el examen.
No tienes que aprender Python o programación sensata para el examen, pero para el
mundo real te sugiero que aprendas ambos.
Entonces, aquí hablan de la separación del plano de control y el plano de datos.
Solo tenga en cuenta dónde está el dispositivo local del cerebro.
En los viejos tiempos, el plano de reenvío del plano de control o el plano de datos estaba en el dispositivo.
Entonces, piense en el plano de datos como el reenvío a través del ASX.
Tengo un enrutador.
El tráfico llega a una interfaz, se cambia a otra interfaz, por lo que los datos se envían a través
del dispositivo.
Se activa en el plano de datos o en el plano de reenvío que aún reside en el dispositivo.
Por lo general, se hace usando A6 pero el plano de control o el cerebro donde reside.
Hoy todavía queremos tener el cerebro en el flujo abierto del dispositivo, el cerebro fue removido y puesto en
un controlador separado.
No queremos hacer eso.
Los dispositivos Cisco realmente no admitían flujo abierto.
Todavía no lo hacen.
La idea es que el cerebro permanezca en el dispositivo, pero podemos usar un controlador centralizado para configurar
los dispositivos.
Entonces, en lugar de hacer que el dispositivo esté hecho, todavía les permitimos hacer
su reenvío, aún les permitimos tener su cerebro local, pero podemos configurar los dispositivos directamente o a través de un
controlador que facilita la administración de muchos dispositivos.
Esa es una de las ideas centrales de una red basada en un controlador.
Ahora, lo que no he mencionado, ella tiene el juego de gestión en realidad tres aviones de control o de
reenvío.
Es como decir escribir un enrutador.
Cómo se reenvía el tráfico a través del dispositivo.
Eso siempre permanece en el dispositivo porque queremos un cambio o reenvío de alta velocidad en el cerebro
del dispositivo, donde reside típicamente en el dispositivo.
Pero podríamos haberlo puesto en un controlador.
¿Dónde está la gerencia?
Entonces, ¿cuál es el plan de gestión?
Normalmente gestionamos un dispositivo Cisco utilizando una consola o remotamente sería una mala idea de Telnet y SSA.
Entonces, ¿cómo administramos el dispositivo ahora? Nosotros, como humanos, usaríamos una de esas interfaces para configurar el dispositivo,
pero para administrar el dispositivo usando una aplicación que en los viejos tiempos usaríamos el protocolo simple de administración de
red SMP si un MP tiene problemas.
Nadie es un MP que Virgin quería ser inseguro, muy fácil de hackear.
Mala idea de usar S&P versión 1 y versión 2.
Es un MP versión 3 que soporta el cifrado y la autenticación mucho mejor, pero es un MP no es fácil.
El OED y la forma de extraer información de un dispositivo es difícil, por lo que la furia actual que ha
estado sucediendo durante algunos años es usar nuevamente una interfaz de programación de aplicaciones API.
El descanso es una de las API más populares que se usa en todo el lugar.
Entonces, cuando pasamos de ser un ingeniero de redes puro a hacer más programación.
Los chicos del mundo de la programación están acostumbrados a descansar api.
Usaron todo el lugar una vez más en las aplicaciones.
Entonces, cuando desean configurar dispositivos de red, tiene sentido que ese dispositivo tenga una API de descanso, pero solo tenga en cuenta
que muchos dispositivos antiguos no tendrán una API de descanso.
Debe usar un dispositivo de red Cisco moderno para obtener una API de descanso.
Entonces, el hecho de que el descanso sea bueno no significa que todos los dispositivos admitirán el descanso.
Entonces, en los ejemplos que les mostraré en este curso, que está muy basado en mi curso
original de Python, les mostraré cómo configurar los dispositivos usando telnet y SSA.
Porque esa es una manera fácil de comenzar.
Comience con lo básico en CCN un nivel, luego vaya y haga su examen asociado definitivo.
Le recomiendo que haga la certificación definitiva para obtener su certificación definitiva para
que pueda demostrar a los empleadores que no solo es un ingeniero de redes sino que también comprende la programación.
Ahora, como he dicho, he estado hablando de programación durante mucho tiempo.
Hablé sobre flujo abierto hace más de cinco años.
Entonces, la idea es que estas cosas han estado surgiendo en la industria, pero ahora Cisco lo ha formalizado.
Por lo tanto, mi recomendación es aprender Python y aprender las cosas para el mundo real, no para el CCMA solitario para el mundo real
y para la certificación definitiva y ve y obtén tu certificación definitiva tan pronto como puedas
para que puedas demostrar a los empleadores que No solo eres un ingeniero de redes sino
que también entiendes la programación.
Me temo que, al ser un ingeniero de redes tradicional sin conocimiento de la programación, tendrá que aprender
a programar si desea tener un buen trabajo en el futuro. Estoy muy contento de que Cisco
haya hecho esto, pero solo han puesto 10 El porcentaje del examen es automatización y programación, por lo que
la capacidad del programa de automatización El 10% del examen no es muy grande y usan palabras como explicar y comparar.
No usan palabras como configurar o solucionar problemas, por lo que este es un nivel muy alto.
Esta es la forma típica de Cisco de hacerlo a un nivel muy alto, pero tal vez en la próxima versión
de CCMA se volverá más detallado y se le pedirá más información.