Capítulo 1. Introducción Introducción

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

¡Bienvenido al mundo de la automatización de la gestión de Junos! Desde su introducción a finales de los 90, la interfaz de usuario (UI) del software Junos lo ha diferenciado de sus competidores al facilitar a los operadores de red la gestión de sus dispositivos mediante la interfaz de línea de comandos (CLI). Además, Juniper ha sido líder en automatización de redes, distribuyendo una API en la primera versión de Junos y ofreciendo la primera API externa en Junos 4.1.

Sin embargo, los tiempos han cambiado. Cada vez más, a medida que los operadores buscan automatizar sus redes, otras interfaces de gestión están cobrando importancia. Juniper ha seguido esta tendencia y se esfuerza por ser líder del sector permitiendo que la automatización funcione con sus dispositivos.

Este capítulo prepara el terreno para el resto del libro hablando de las ventajas de la automatización, repasando algunos antecedentes sobre el funcionamiento del sistema de gestión de Junos y dando información básica sobre el libro.

Ventajas de la automatización

La automatización de redes se ha convertido en un tema candente en los últimos años, y con razón: los beneficios de la automatización son bastante grandes, tanto para una empresa como para las personas que gestionan su red.

Como estás leyendo este libro, probablemente ya conoces al menos algunas de las ventajas de la automatización. Sin embargo, nos parece que siempre que revisas las posibilidades de la automatización, puedes encontrar una nueva forma de utilizarla más allá de las que tenías previstas. Repasemos algunas ventajas habituales.

La automatización ahorra tiempo

Una de las ventajas básicas de la automatización más es que ahorra tiempo. Muchos de nosotros tenemos tareas repetitivas que debemos realizar. Un método para simplificar estas tareas repetitivas es utilizar la automatización.

Por ejemplo, supongamos que tienes una metodología estándar para solucionar problemas de sesiones fallidas del Protocolo de Pasarela Fronteriza (BGP) . En primer lugar, comprueba la salida show interfaces de la interfaz conectada al peer. Después, haces ping al peer. Después, miras en la salida show bgp neighborpara el peer. Por último, busca errores de registro relacionados con el peer o su interfaz.

Es completamente aceptable mantener una lista de los comandos apropiados y ejecutarlos cada vez que necesites solucionar una sesión BGP fallida. Sin embargo, puedes ahorrar tiempo reduciéndolos a un script de automatización que ejecute los comandos apropiados.

De hecho, puedes ahorrar aún más tiempo haciendo que el script interprete la salida del comando por ti. Por ejemplo, ¿qué quieres saber realmente de la salida de show interfaces? Probablemente quieras ver si la interfaz está activa o inactiva. Probablemente también quieras buscar estadísticas inusuales (como una tasa de datos muy alta o una tasa de errores elevada). Según lo que veas aquí, puede que ya sepas la razón del fallo de la sesión. (Si el enlace está caído, no es necesario buscar más: no llegará tráfico al peer). Si haces que el script busque pistas obvias como ésta, podrás escribir un script que simplemente te diga por qué se ha caído la sesión BGP cuando sea obvio. (Ese análisis automatizado puede ser de gran ayuda cuando recibas una llamada a las 4 de la mañana para solucionar un problema de red).

Pero, ¿por qué detenerse ahí? ¿Por qué necesitas siquiera ejecutar el script? ¿Por qué no hacer que tu dispositivo ejecute automáticamente el script por ti cada vez que una sesión de peering se caiga y permanezca caída durante más de cinco minutos? Junos tiene los ganchos de automatización para permitir este tipo de ejecución de script basada en eventos.

Y, por supuesto, una de las grandes formas en que la automatización puede ahorrar tiempo es simplificando el repetitivo proceso de aprovisionamiento, que a menudo consiste en utilizar plantillas estándar para rellenar los espacios en blanco. Hablaremos más de ello en "La automatización evita los errores de copiar y pegar".

La automatización evita los errores humanos

El título alternativo de esta sección de debería ser: "La automatización evita las llamadas telefónicas a las 4 de la mañana". ¿Cuántas emergencias se han producido porque alguien ha cometido una errata o una simple omisión durante un cambio?

Por ejemplo, supongamos que el núcleo de tu red utiliza Multiprotocol Label Switching (MPLS) para reenviar el tráfico. Además, supongamos que MPLS es necesario porque tienes un gran número de aplicaciones (como las redes privadas virtuales [VPN]) que requieren MPLS para funcionar correctamente. Ahora imagina que alguien aprovisiona nuevas interconexiones de red entre routers centrales y de perímetro, pero se olvida de habilitar el procesamiento MPLS para esas interfaces en el router central. Este escenario es una interrupción de la red a punto de producirse. Cuando las otras rutas entre el núcleo y los routers de perímetro dejen de funcionar, el tráfico MPLS no podrá fluir por esos nuevos enlaces.

¿No sería estupendo que pudieras evitar que alguien lo hiciera programando la red para que conociera las configuraciones esperadas y detectara omisiones como ésta? De nuevo, Junos dispone de ganchos de automatización para habilitar esta protección.

La automatización ahorra memoria

Probablemente todos tenemos tareas complicadas que sólo necesitamos realizar de vez en cuando. No es raro que responda a la pregunta de un colega rascándome la cabeza y diciendo: "Recuerdo haber buscado el comando para hacer eso. Dame un minuto para encontrarlo".

Es cierto que no todos los comandos deben reducirse a la automatización. Pero las cosas que son especialmente críticas y suelen necesitarse en situaciones en las que el tiempo apremia son buenas candidatas para la automatización. Del mismo modo, las cosas especialmente complicadas también son candidatas a la automatización.

La automatización evita los errores de copiar y pegar

Varias tareas habituales de gestión de red pueden reducirse a seguir una plantilla con variables que hay que completar. Quizás el ejemplo paradigmático de esto sea el aprovisionamiento de red (aunque el mismo concepto puede aplicarse en otros contextos, como la resolución de problemas).

El aprovisionamiento de red suele implicar plantillas : una plantilla para la configuración base del dispositivo, una plantilla para las conexiones internas, una plantilla para las conexiones de tránsito o de pares, y varias plantillas para distintos tipos de conexiones de clientes. Estas plantillas suelen tener muy pocas variables que un operador deba cambiar para utilizarlas. Sin embargo, es fácil que alguien omita accidentalmente una línea importante, olvide cambiar una de las variables o cambie una de las variables a un valor no válido. E incluso si el usuario no comete errores al crear la configuración a partir de la plantilla, a veces se introduce un error durante el proceso de copiar y pegar un gran bloque de configuración o un gran conjunto de comandos.

Nota

Hablaremos más sobre el aprovisionamiento de plantillas cuando hablemos de los scripts de confirmación en el Capítulo 5. Los scripts de confirmación son una forma de aplicar fácilmente una plantilla. Los scripts de confirmación proporcionan incluso una forma opcional de reducir el tamaño del archivo de configuración de Junos haciendo que Junos muestre por defecto los parámetros de la plantilla (en lugar de su expansión completa).

En este caso, la automatización puede ahorrar tiempo y reducir el número de errores involuntarios. Si el proceso de aprovisionamiento se reduce a un simple script que pide valores para las pocas variables que hay en una plantilla, el script puede asegurarse de que se aplica toda la configuración. El script puede incluso hacer las preguntas necesarias para elegir la plantilla correcta. Además, el script puede realizar comprobaciones para validar que los valores proporcionados por el usuario tienen sentido.

De hecho, es posible reducir aún más la información que un usuario tiene que proporcionar haciendo que el script recopile la información en primer lugar. Supongamos que todos los datos de los clientes se mantienen en una base de datos SQL. Cuando el usuario se lo pida, el script puede consultar la base de datos para obtener los valores correctos de todas las variables y presentárselos al usuario para su validación. Esto reduce aún más la posibilidad de errores involuntarios.

A partir de ahí, sólo hay un pequeño paso para automatizar totalmente el proceso. Cuando se añade un nuevo cliente a la base de datos, un proceso automatizado puede activar automáticamente los cambios en la red.

Probablemente no sea posible eliminar por completo la posibilidad de que alguien introduzca información incorrecta en algún momento del proceso. Sin embargo, el uso de la automatización puede reducir el número de lugares en los que puede introducirse información incorrecta. Y puede fomentar la coherencia entre los distintos sistemas que mantienen información sobre la red, garantizando que se utilice la misma información en todas partes (tanto si es correcta como incorrecta).

La automatización permite nuevos servicios

La automatización puede permitir nuevos servicios que no podrían ser realizados por humanos de forma eficiente. En este contexto, un "servicio" puede ser externo o interno.

SDN puede ser un buen ejemplo de un servicio externo habilitado por la automatización. Imagina que un operador de red quiere optimizar su flujo de tráfico cada cinco minutos basándose en un complejo conjunto de algoritmos, pero quiere realizar el recálculo más rápido que eso si se producen determinados eventos. Éste es el tipo de servicio de red complejo que requiere automatización para implementarlo eficazmente.

Un ejemplo de servicio interno habilitado por la automatización es un servicio automatizado de solución de problemas. Imagina que un operador de red implementa un servicio automatizado de solución de problemas que monitoriza los eventos de red que puedan indicar un error de red. La herramienta de automatización responde a esos eventos según una plantilla de solución de problemas establecida. Si encuentra un problema que puede corregir automáticamente, lo hace. Si no, envía el resultado de sus hallazgos al sistema de tickets de problemas del operador de red. Esa salida debe contener toda la información necesaria para seguir solucionando el problema. Esto puede reducir la cantidad de tiempo que los ingenieros de red dedican a recopilar información básica y a intentar soluciones "sencillas". También tiene el potencial de suprimir los errores falsos, reduciendo la cantidad de tiempo que los ingenieros de red pasan respondiendo a falsas alertas y permitiéndoles empezar a trabajar en los problemas reales más rápidamente. Por último, tiene el potencial de reducir el tiempo de resolución de los problemas de red.

Sistema de gestión interno

Es útil tener una buena comprensión en de la forma en que los "datos de gestión" suelen fluir por el sistema Junos. Algunos ejemplos de los tipos de datos de gestión que pueden fluir por un sistema son la información de configuración, los comandos operativos y las estadísticas. Comprender bien este flujo de datos de gestión te ayudará a entender las distinciones entre los distintos métodos de acceso a estos datos.

Al examinar el flujo de datos de gestión, verás que el demonio de gestión (MGD) es un eje central de actividad. La mayoría de los datos de gestión fluyen a través del MGD. El software de Junos acepta conexiones de gestión a través de diversos mecanismos; sin embargo, la mayoría acaban convirtiéndose en sesiones Junoscript o NETCONF que se conectan a MGD. MGD dispone de tres mecanismos principales para interactuar con los demonios: un socket de gestión (que utiliza para transmitir solicitudes y respuestas de comandos operativos), la base de datos de configuración compartida y las señales Unix.

Acceder al Sistema de Gestión

Empecemos por las vías de acceso al sistema de gestión . Aquí, todos los caminos conducen a MGD.

Todas las sesiones CLI invocan a un binario (casualmente, llamado cli) que es un cliente Junoscript. El binario CLI abre una sesión Junoscript con MGD e intercambia información con MGD en un formato XML .

También es posible que un usuario interactúe con el software Junos utilizando una sesión NETCONF o Junoscript. Estas sesiones también se conectan a MGD.

Además, un usuario puede interactuar con el software Junos utilizando la API REST . Como se describe en "Diseño interno", estas sesiones se canalizan a través de algunas tuberías adicionales, pero finalmente llegan a MGD.

Por último, es posible que un usuario interactúe con el software Junos utilizando PyEZ, o que los scripts op, commit o de eventos lancen llamadas a procedimientos remotos (RPC). En todos estos casos, se utiliza una sesión Junoscript o NETCONF para conectarse al software. De nuevo, todas estas sesiones Junoscript o NETCONF terminan con MGD.

La Figura 1-1 ilustra cómo todos estos diversos mecanismos de conexión acaban convirtiéndose en sesiones conectadas a MGD.

This figure illustrates the way various management connections end up as sessions connected to MGD. CLI connections and REST API connections become Junoscript connections to MGD. PyEZ, op, commit, and event scripts can launch RPCs by opening Junoscript or NETCONF sessions to MGD. Finally, a user can directly open a NETCONF or Junoscript connection to MGD.
Figura 1-1. Diversas conexiones de gestión que se conectan a la MGD

Flujo de mando operativo

Las órdenes operativas llegan a MGD a través de uno de los métodos de conexión que acabamos de describir. Cuando MGD recibe las órdenes operativas, puede satisfacerlas por sí mismo, pasarlas a otros demonios para que las satisfagan o invocar a otras herramientas para que las satisfagan.

Por ejemplo, el comando RPC get-authorization-information (que equivale a el comando CLI show cli authorization ) es un ejemplo prototípico del tipo de petición que MGD satisface por sí mismo. Con este comando, el usuario pide información sobre su nivel de autorización. Se trata de información que MGD mantiene para cada sesión, y es fácil que MGD satisfaga esta petición por sí mismo. show configuration (Otro ejemplo prototípico de esta categoría es el RPC get-configuration, o el comando CLI .) De nuevo, esta petición solicita información que MGD mantiene internamente).

Dos ejemplos clásicos de los tipos de comandos operativos que se pasan a un demonio son el RPC get-route-information(equivalente a el comando CLI show route ) y el RPC clear-bgp-neighbor (equivalente al comando CLI clear bgp neighbor ). En ambos casos, el demonio del protocolo de enrutamiento (RPD) es el demonio que satisface esta petición. Es el dæmon que mantiene la información sobre la tabla de enrutamiento (también conocida como base de información de enrutamiento, o RIB); por lo tanto, es el dæmon que puede responder autoritariamente a una solicitud de información de ruta. Del mismo modo, RPD es el dæmon que mantiene las relaciones de vecinos BGP; por lo tanto, es el dæmon que gestiona una solicitud para restablecer una de esas relaciones. En estos casos, MGD actúa como una tubería bidireccional, pasando la petición del usuario a RPD y pasando la respuesta de RPD al usuario. La Figura 1-2 ilustra este flujo de datos. Para soportar esta comunicación, MGD mantiene un socket de gestión con la mayoría de los demonios. Las peticiones y respuestas operativas fluyen a través de este socket de gestión.

En algunos casos, MGD invoca herramientas para satisfacer peticiones. Un ejemplo es el proceso de actualización de Junos, que requiere un manejo más complejo que un comando CLI normal. MGD invoca una herramienta externa para realizar parte de la actualización. Otro ejemplo son los scripts op y commit, que en realidad se ejecutan mediante la utilidad CSCRIPT. Todo este proceso es transparente para el usuario, y sólo se incluye aquí en aras de la exhaustividad.

Nota

Como ilustra la Figura 1-2, algunas peticiones deben llegar hasta el motor de reenvío de paquetes (PFE) para ser satisfechas. Las estadísticas de interfaz son un ejemplo de este tipo de petición. Para recopilar las estadísticas de la interfaz, el MGD invoca a ifinfo, que consulta al núcleo. A menudo, el núcleo necesita consultar a un PFE para obtener estas estadísticas. De este modo, los comandos operativos tienen a veces importantes repercusiones en el sistema.

This figure illustrates the way that MGD handles requests satisfied by a daemon or external process. MGD passes the request to the daemon or external process. When the daemon or process responds, MGD passes the response to the client.
Figura 1-2. Flujo de datos entre un usuario y un demonio

Flujo de datos de configuración

Cuando envías los cambios de configuración a , los nuevos datos de configuración se colocan en una base de datos compartida a la que pueden acceder todos los demonios. Cuando esta base de datos de configuración cambia, MGD utiliza señales Unix para indicar a los demonios apropiados que vuelvan a leer la nueva configuración. Tras leer la configuración, los demonios activan su contenido. Si la nueva configuración requiere cambios en el plano de reenvío, estos datos se propagarán a los PFE. Este proceso se ilustra en la Figura 1-3.

This figure illustrates the way committed configuration data is disseminated to daemons. First, MGD places the data in a shared database. Then, MGD signals the daemons. Finally, the daemons read the data from the shared database and activate it.
Figura 1-3. Flujo de datos de configuración

Bases de datos de configuración y el modelo Commit

El resto de este libro asume cierto conocimiento de las bases de datos de configuración y del modelo de commit. Aunque se trata de información básica, es importante que repases estos conceptos para comprender las partes del libro en las que se hace referencia a ellos.

Bases de datos de configuración

Cada sistema Junos tiene al menos dos bases de datos de configuración : la configuración comprometida y la configuración candidata. Como implican los nombres, la configuración confirmada es la configuración que está activa en ese momento, mientras que la configuración candidata es la copia de la configuración que un usuario está editando. Como se ilustra en la Figura 1-5, cuando un usuario confirma la configuración, la configuración candidata pasa a ser la configuración confirmada y una copia de la nueva configuración confirmada pasa a ser la configuración candidata. El software de Junos guarda una copia de cada configuración confirmada anterior por si necesitas hacer referencia a ellas en el futuro. (Puedes hacer referencia a estas configuraciones guardadas como las configuraciones de rollback).

This figure shows the way the configuration databases are changed during a commit operation. The candidate configuration becomes the committed configuration. The software makes a copy of the new committed configuration and uses it as the candidate configuration.
Figura 1-5. Una configuración candidata se convierte en la configuración comprometida

Ten en cuenta el lenguaje específico: la nueva configuración candidata es una copia de la nueva configuración confirmada. En algunos casos (en particular, cuando un script de confirmación modifica la configuración como parte de una confirmación), la nueva configuración confirmada puede no coincidir con la configuración candidata en el momento en que el usuario activa la confirmación.

La base de datos compartida de configuración de candidatos

Cuando un usuario introduce el comando configure, por defecto comenzará a editar la base de datos de configuración de candidatos compartida. Como se ilustra en la Figura 1-6, todos los usuarios editarán la misma base de datos de configuración candidata. Este comportamiento deja abierta la posibilidad de que varios usuarios puedan tener interacciones involuntarias entre sí si están editando la configuración al mismo tiempo. Cualquier cambio realizado en una sesión afectará a cualquier otra sesión de configuración que utilice la base de datos compartida. Y cada vez que un usuario confirme la base de datos compartida, confirmará todos los cambios realizados en la base de datos compartida, independientemente de quién haya realizado los cambios.

Puede ser muy peligroso confirmar los cambios en la base de datos compartida mientras varios usuarios la están editando. Supongamos que user1 está configurando una sesión BGP mientras user2 está cambiando la dirección IP asignada a una interfaz de cliente. Imagina que user1 crea una nueva sesión BGP, pero aún no ha asignado una política de importación cuando user2 termina su trabajo y confirma la configuración. La Figura 1-7ilustra lo que ocurre.

This figure shows multiple users editing the single shared candidate configuration database. Their changes impact the shared data in this configuration database.
Figura 1-6. Varios usuarios editando la base de datos compartida de configuración de candidatos
This figure shows two users editing the single shared candidate configuration database. User 2 commits part of the changes User 1 is entering.
Figura 1-7. Compromiso de una base de datos de configuración de candidatos compartida incompleta

La configuración confirmada contiene ahora una sesión BGP sin política de importación. Dado el potencial de problemas que puede causar, muchos proveedores de servicios lo considerarían un error.

Y puede ser incluso peor. Es fácil imaginar un escenario en el que un usuario provoque una interrupción al comprometer una configuración parcial añadida por otro usuario.

Para ayudar a detectar estas situaciones, Junos te avisará si entras en una sesión de configuración utilizando la base de datos compartida mientras otros usuarios están editando esa base de datos:

user1@r0> configure
Entering configuration mode
Users currently editing the configuration:
  user2 terminal p0 (pid 38905) on since 2015-04-25 07:27:27 PDT 1
      [edit protocols bgp] 2
  user1 terminal p1 (pid 38903) on since 2015-04-25 07:28:18 PDT, idle 00:28:09
      [edit interfaces ge-0/0/0]
The configuration has been changed but not committed 3

[edit]
user1@r0#
1

Esta línea muestra una sesión de usuario que está editando la configuración. Incluye información sobre la sesión de usuario, como el terminal que está utilizando, la hora a la que empezó a editar la configuración y el tiempo que ha estado inactiva.

En este caso, hay otras dos sesiones de usuario editando la configuración; por tanto, hay dos entradas, una para cada sesión. Como puedes ver, la segunda entrada muestra que user1 ya está editando la configuración. ¡Esto puede recordarle a user1 una sesión de configuración que había olvidado!

2

Esta línea muestra la jerarquía de configuración que está editando un usuario. Esta información proporciona alguna pista sobre el área de configuración que el usuario está modificando. Sin embargo, la CLI de Junos es lo suficientemente flexible como para que un usuario pueda estar editando cualquier parte de la configuración en cualquier momento. (Si no, puede utilizar el comando edit para pasar a una nueva parte de la configuración justo después de que aparezca este mensaje). Por tanto, conviene ser un poco escéptico con esta información, comprendiendo que sólo muestra una instantánea de la información en un momento dado.

3

Este texto se muestra siempre que la base de datos de configuración candidata compartida contenga cambios que no se hayan confirmado. Puede aparecer aunque no haya otros usuarios editando la base de datos compartida. Este texto advierte al usuario de que puede haber otros cambios que activará si confirma la configuración candidata. Un usuario puede entrar en show | compare para mostrar los cambios que se han realizado en la configuración candidata.

Si realizas cambios en la base de datos de configuración de candidatos compartidos e intentas salir sin confirmarlos, el programa te advertirá de ello y te pedirá que confirmes tus intenciones:

[edit]
user@r0# exit
The configuration has been changed but not committed
Exit with uncommitted changes? [yes,no] (yes)

Hay ocasiones en las que es conveniente salir con los cambios en la base de datos compartida, pero esta acción también entraña peligros potenciales. Cualquier usuario puede confirmar accidentalmente estos cambios antes de lo que tú pretendías, u otro usuario puede modificar o borrar tus cambios. Estos peligros son parte de la razón de la advertencia que aparece en la CLI.

Otros modos de edición de la configuración

Además de editar la base de datos de configuración de candidatos compartida, hay al menos otras dos formas de editar la configuración: puedes editar la base de datos de configuración de candidatos compartida en modo exclusivo, o puedes editar una configuración de candidatos privada.

Modo de configuración exclusivo

Cuando introduces configure exclusive, el programa se asegura de que serás el único que realice cambios en la base de datos compartida de configuración de candidatos. Además, se asegura de que nadie más haya realizado previamente cambios no confirmados en la base de datos compartida. Por último, no te permitirá guardar los cambios en la base de datos compartida de configuración de candidatos a menos que los confirmes.

Nota

Este comportamiento hace que el modo de configuración exclusiva sea bastante útil para los scripts automatizados de . Garantiza que no interactuarán con otras sesiones de configuración de forma inesperada. Las sesiones de configuración que utilizan NETCONF pueden obtener un comportamiento equivalente utilizando la llamada a procedimiento remoto lock-configuration. NETCONF se trata en "Aspectos internos del sistema de gestión" y las RPC se tratan en el Capítulo 2.

Si intentas entrar en el modo de configuración exclusiva mientras otra persona está editando la base de datos de configuración de candidatas compartidas , verás un error:

user1@r0> configure exclusive
error: configuration database locked by:
  user2 terminal p0 (pid 38905) on since 2015-04-25 08:34:03 PDT, idle 00:04:20
      exclusive [edit]

user1@r0>

Del mismo modo, verás un error si intentas entrar en el modo de configuración exclusiva mientras haya cambios no comprometidos en la base de datos de configuración compartida:

user@r0> configure exclusive
error: configuration database modified

user@r0>

Por último, cuando entres en el modo de configuración exclusiva, el programa te advertirá de que no puedes guardar los cambios no comprometidos en la base de datos de configuración candidata compartida cuando salgas. Y si intentas salir con cambios no comprometidos, te pedirá que confirmes que quieres descartar estos cambios :

user@r0> configure exclusive
warning: uncommitted changes will be discarded on exit
Entering configuration mode

[edit]
user@r0# set system host-name r1

[edit]
user@r0# exit
The configuration has been changed but not committed
warning: Auto rollback on exiting 'configure exclusive'
Discard uncommitted changes? [yes,no] (yes)

Modo de configuración privado

Otra opción para controlar las interacciones no deseadas entre sesiones de configuración es trabajar en copias privadas de la base de datos de la configuración candidata(Figura 1-8). Esta opción tiene algunas de las mismas restricciones que trabajar en una copia exclusiva de la configuración candidata, excepto que permite la edición simultánea de la configuración. Una vez que confirmes tus cambios, éstos se aplicarán a la configuración confirmada. De forma similar a como funcionan los sistemas de control de revisiones (como SVN o CVS), el software de Junos puede fusionar cambios no conflictivos de varias sesiones simultáneas; sin embargo, el software no puede fusionar cambios conflictivos.

This figure shows multiple users editing private candidate configuration databases. Each user's changes go into his own database. Each user can commit the changes from her database separately.
Figura 1-8. Varios usuarios editando bases de datos de configuración privadas

Cuando entras en configure private , el software de Junos crea una nueva copia privada de la configuración comprometida del dispositivo. Tus cambios irán a esta copia privada de la configuración. El software de Junos se asegurará de que nadie más haya realizado previamente cambios no comprometidos en la base de datos compartida de la configuración candidata. (No pasa nada si otras personas realizan cambios en otras bases de datos privadas). Por último, no te permitirá guardar los cambios en la base de datos privada de configuración candidata a menos que los confirmes.

Nota

Este comportamiento hace que el modo de configuración privada sea útil para los scripts de automatización. Garantiza que una sesión automatizada no confirmará los cambios de otra sesión de configuración. Y, a diferencia de lo que ocurre con el modo de configuración exclusiva, varios scripts pueden trabajar simultáneamente realizando cambios que no se solapen utilizando el modo de configuración privada.

En comparación con el modo de configuración exclusiva, hay que tener en cuenta algunos modos de fallo diferentes. Por ejemplo, es probable que el script no pueda resolver automáticamente los conflictos con sus cambios. Y, aunque varios scripts pueden trabajar aplicando cambios a sus propias bases de datos de configuración simultáneamente, se requiere un commit separado para activar los cambios de cada base de datos de configuración privada, y los commits reales siguen ocurriendo en serie.

Las sesiones de configuración que utilizan NETCONF pueden obtener un comportamiento equivalente a utilizando la opción private del RPC de abrir configuración:

<open-configuration>
    <private/>
</open-configuration>

Este ejemplo proporciona una vista previa de la sintaxis XML que Junos utiliza para las RPC. En el Capítulo 2 se proporciona información adicional sobre las RPC y esta sintaxis XML.

Si otro usuario confirma un cambio conflictivo antes de que tú confirmes tus cambios, puedes recibir una advertencia cuando confirmes tus cambios. Aquí, dos usuarios intentan configurar las mismas interfaces. El segundo usuario obtiene esta salida:

[edit]
user2@r0# set interfaces ge-0/0/0 description "description #2"

[edit]
user2@r0# set interfaces ge-0/0/1.0 family inet address 192.168.1.1/24

[edit]
user2@r0# commit
[edit interfaces ge-0/0/0 description]
  'description "description #1"'
    warning: statement exists (discarding old value, replacing with 'description
#2') 1
[edit interfaces ge-0/0/1]
  'unit 0'
    warning: statement already exists 2
[edit interfaces ge-0/0/1 unit 0 family]
  'inet'
    warning: statement already exists

[edit]
user2@r0#
1

Esta advertencia muestra que hay un conflicto para un elemento que sólo puede tener un valor. Una interfaz sólo puede tener una descripción. Aquí, la descripción actual es description #1. La advertencia indica que el software Junos sustituirá esa descripción por la nueva (description #2) si user2continúa con la operación de confirmación.

2

Esta advertencia muestra que existe un conflicto para una parte de la jerarquía de configuración que puede ser fusionable. Esta advertencia indica que el software de Junos intentará fusionar los cambios de user2en esta jerarquía de configuración con otros cambios que ya haya realizado otro usuario en la misma jerarquía de configuración.

Cuando recibes una advertencia como ésta, el software Junos no continúa con la operación de confirmación. (Esto se indica mediante la ausencia de un mensaje commit complete en la CLI, el elemento <commit-success/> en la salida Junoscript o el elemento <ok/> en la salida NETCONF.) Cuando te encuentres con esta situación, tienes dos opciones para seguir adelante con la confirmación.

En primer lugar, puedes utilizar el comando update para fusionar los cambios de la configuración confirmada actual en tu base de datos privada. Por lo general, el programa no sobrescribe tus cambios, sino que calcula la configuración resultante de fusionar tus cambios con la configuración actual confirmada y la instala en tu base de datos privada. (Tal vez sea útil pensar que esto es análogo a un git rebase.) Puedes ver los resultados de esta fusión examinando tu base de datos de configuración privada.

Una vez que hayas actualizado tu base de datos privada, puedes confirmar los cambios sin recibir otra advertencia (a menos, por supuesto, que otro usuario realice más cambios conflictivos entre el momento en que actualizas tu base de datos y el momento en que confirmas los cambios).

La otra cosa que puedes hacer cuando recibas una advertencia como ésta es simplemente ejecutar de nuevo el comando commit. Esta acción hace que el software Junos intente fusionar tus cambios en la configuración confirmada. En general, no se recomienda ejecutar un segundo comando commit, ya que es posible que no puedas predecir con exactitud la configuración final que resultará de estos cambios. Sin embargo, si consideras plenamente las consecuencias, puedes optar por utilizar esta funcionalidad .

Consejo

Puedes elegir mezclar los modos de configuración exclusivo y privado. Si lo haces, podrás abrir una base de datos de configuración privada mientras otro usuario mantiene un bloqueo exclusivo en la base de datos de configuración. Sin embargo, no podrás confirmar los cambios realizados en tu base de datos privada mientras otro usuario tenga un bloqueo exclusivo en la base de datos de configuración. En su lugar, recibirás un error. Tendrás que esperar a que el usuario libere el bloqueo exclusivo, momento en el que podrás continuar con la operación de confirmación.

El proceso de compromiso

Cuando ejecuta el comando commit, el software de Junos sigue un proceso cuidadosamente orquestado para garantizar que el dispositivo acaba con una configuración utilizable.

Nota

En este proceso, describimos un sistema con motores de enrutamiento (RE) redundantes. De hecho, describimos un sistema con más de dos REs, ya que ese sistema sigue el proceso de confirmación más complicado. Para simplificar este proceso para un sistema con menos REs (incluso un sistema de un solo RE), simplemente omite los pasos que se aplican a los otros REs.

Los pasos son los siguientes:

  1. El RE maestro ejecuta sus comprobaciones de confirmación. Esto puede incluir:

    • Comprobación de la coherencia de los datos. (Por ejemplo, si un grupo BGP hace referencia a una política, esa política debe estar definida).

    • Ejecutar scripts de confirmación. (Los scripts de confirmación pueden devolver advertencias o errores que se detectan en esta fase).

    • Ejecutar demonios en un modo especial que realice un análisis más profundo de la configuración candidata.

  2. El RE maestro envía la configuración a los demás REs y les pide que realicen sus comprobaciones de confirmación.

  3. Las demás ER activan la nueva configuración.

  4. El ER maestro activa la nueva configuración.

Si se detecta un error en cualquier paso del proceso, se aborta el proceso de confirmación y el software vuelve a utilizar la configuración activa anterior.

Este proceso impone un contrato con el usuario: Junos se tomará el tiempo necesario para validar exhaustivamente que la configuración es aceptable y, a cambio, garantizará que los componentes de software de Junos podrán analizar la configuración al final del proceso. En esencia, estás sacrificando tiempo a cambio de fiabilidad.

Validar la configuración

Configuración La validación se produce en varias etapas.

A medida que introduces sentencias de configuración, el demonio de gestión valida que cada sentencia sea sintácticamente correcta. (Aquí, "corrección sintáctica" se refiere a que cada comando esté correctamente formado y construya un bloque de configuración válido). Si detecta algún problema, suele rechazar la sentencia de configuración.

Además, MGD realiza algunas comprobaciones semánticas a medida que modificas la configuración. (Aquí, "corrección semántica" se refiere al estado en el que toda la configuración es coherente y comprensible). Si detecta un problema, suele añadir un comentario a la configuración para advertirte de él. En este ejemplo, la configuración BGP hace referencia a una política de exportación, pero la política a la que hace referencia no está en la configuración:

[edit]
user@r0# show protocols bgp export
export does_not_exist; ## 'does_not_exist' is not defined

Una vez que confirmes la configuración, MGD volverá a realizar sus comprobaciones semánticas; sin embargo, estas comprobaciones darán lugar a un error o a una advertencia, según corresponda. Por ejemplo, si intentas confirmar la configuración con la política de exportación BGP aún sin definir, verás este mensaje:

[edit]
user@r0# commit
error: Policy error: Policy does_not_exist referenced but not defined
[edit protocols bgp]
  'export'
    BGP: export list not applied
error: configuration check-out failed

Si se superan las comprobaciones semánticas de MGD, MGD aplica las secuencias de comandos de confirmación enumeradas en la configuración candidata. Los scripts de confirmación pueden devolver advertencias o errores. Las advertencias se muestran al usuario, pero no afectan al proceso de confirmación. Los errores se muestran al usuario y abortan el proceso de confirmación. (Hay más información sobre los scripts de confirmación en el Capítulo 5.)

Si los scripts de confirmación no devuelven errores, MGD llama a los distintos demonios interesados en los cambios y les pide que verifiquen que la configuración es semánticamente correcta. Estos demonios pueden devolver advertencias o errores. De nuevo, ambos se muestran al usuario, pero sólo los errores abortan el proceso de confirmación.

Consejo

Utiliza el comando commit check para ver los resultados de estas comprobaciones de confirmación sin confirmar realmente la configuración.

Activar la configuración

Cuando el RE activa la nueva configuración, ésta se fusiona con otros datos (como los valores predeterminados de la plataforma y los cambios transitorios de los scripts de confirmación). Entonces, la nueva configuración se convierte atómicamente en la nueva configuración "activa".

Consejo

Puedes ver los valores predeterminados de una plataforma concreta ejecutando el siguiente comando :

show configuration groups junos-defaults

Estas declaraciones de configuración se aplican como cualquier otro grupo de configuración. Eso significa que pueden ser anuladas por la configuración del usuario. (Dicho de otro modo, los grupos de configuración se aplican "detrás" de la configuración proporcionada por el usuario, lo que significa que la configuración proporcionada por el usuario puede ocultar partes conflictivas de la configuración por defecto). Es una forma elegante y prolija de decir que las sentencias de configuración por defecto se comportan exactamente como cabría esperar que se comportaran las sentencias de configuración por defecto.

Dæmons de señalización

Una vez que la configuración está confirmada, MGD realiza los cambios que necesite (como añadir o eliminar cuentas de usuario, u otros cambios de los que MGD sea responsable) y envía señales a otros demonios para que lean la nueva configuración y activen los cambios de configuración de los que cada uno es responsable. Como el software de Junos rastrea los cambios que ha hecho un usuario, sólo necesita enviar señales a los demonios interesados en las partes de la configuración que han cambiado. Por tanto, dependiendo del cambio exacto, MGD puede indicar a más o menos demonios que relean la configuración. Esto significa que el dispositivo puede hacer más o menos trabajo por cada cambio de configuración, dependiendo del contenido del cambio.

Nota

Este comportamiento adquiere mayor relevancia a medida que aumenta el tamaño de la configuración. Por ejemplo, el demonio de protocolo de enrutamiento (RPD) de tarda mucho menos tiempo en leer una configuración con una sola instancia de enrutamiento y 10 rutas estáticas que en leer una configuración con 1.000 instancias de enrutamiento y 400.000 rutas estáticas. Conocer la naturaleza del rendimiento de tus confirmaciones puede ayudarte a desarrollar estrategias inteligentes para gestionar las confirmaciones de configuración.

Puedes ver este comportamiento añadiendo la directiva | display detail al extremo del comando commit. Esto hace que la CLI muestre los detalles sobre las actividades que MGD realiza para activar la configuración. Entre otros detalles, deberías ver a qué demonios señala MGD para que relean la configuración.

En raras circunstancias puedes encontrarte con un error en la lógica que puede hacer que MGD no señale a un demonio. (A Juniper no le gusta ver esos fallos, pero pueden ocurrir ocasionalmente). En esos casos, puedes utilizar el comando commit full para hacer que MGD realice todas las acciones para confirmar toda la configuración sin tener en cuenta lo que ha cambiado. Si haces esto, MGD actúa como si toda la configuración hubiera cambiado y se indica a todos los demonios que vuelvan a leer su configuración.

Crear la vista de configuración fusionada

La Figura 1-9 muestra en una ampliación más completa de la forma en que los datos de configuración, incluidos los cambios transitorios en los scripts de confirmación y los valores por defecto de la plataforma, se combinan en una "vista fusionada" que los demonios pueden utilizar para activar la nueva configuración.

This figure shows how configuration data is merged together. Transient commit script changes take precedence over the static configuration. The static configuration takes precedence over configuration groups (including the platform defaults). This configuration data is merged together into a "merged view", which is what the daemons read when they activate the configuration.
Figura 1-9. La combinación de información de configuración procedente de múltiples fuentes

En general, los datos de configuración se aplican con esta precedencia:

  1. Cambios transitorios de los scripts de confirmación

  2. La configuración confirmada (ten en cuenta que esto incluye cualquier cambio permanente realizado por un script de confirmación)

  3. Configuración aplicada desde grupos de configuración (que incluye los valores por defecto de la plataforma)

Nota

El Capítulo 5 contiene más información sobre los scripts de confirmación, incluida la diferencia entre cambios de configuración transitorios y permanentes. Por ahora, basta con entender que los scripts de confirmación pueden producir distintos tipos de cambios, que se aplicarán con distinta precedencia.

En realidad, para ser un poco más preciso, se fusionan los cambios transitorios de los scripts de confirmación, la configuración confirmada y los grupos de configuración de la configuración estática. Una vez fusionados los datos de estas distintas fuentes, esta vista "fusionada" de la configuración (puedes llamarla configuración "post-inherencia") es lo que leen los distintos demonios cuando activan una nueva configuración de .

Nota

Los grupos de configuración sólo se aplican a la configuración de la base de datos de configuración estática. No se aplican a los cambios transitorios de los scripts de confirmación.

Información sobre el libro

La automatización de redes se produce en la interesante intersección de la programación y la ingeniería de redes. Sin duda hay buenos programadores que también son excelentes ingenieros (o viceversa), pero tenemos que ser honestos con nosotros mismos y darnos cuenta de que esas pocas personas probablemente quepan en una habitación bastante pequeña.

Lo que es mucho más habitual es que un ingeniero de redes decida hacer algo de programación, o que a un programador se le encargue aplicar sus conocimientos a la automatización de redes. Esto ocurre por varias razones. Quizás una empresa pide a un ingeniero de redes que implemente nuevos servicios que requieren automatización, como la SDN. O quizá un ingeniero de redes simplemente decide que quiere automatizar sus tareas para ahorrar tiempo. O puede que una empresa contrate a un programador para implantar la automatización de la red. Sea como sea, es fácil quedarse atascado fuera de tu zona de confort si te piden que combines habilidades que ya tienes con otras nuevas para hacer algo que parece realmente complicado, como la automatización de redes.

Nuestro objetivo es ayudarte a que el aprendizaje de estas nuevas habilidades te resulte más sencillo. Si estás muy familiarizado con el manejo de dispositivos Junos, te daremos la información que necesitas para utilizar esas habilidades en la automatización de redes. La automatización de redes no tiene por qué ser complicada. De hecho, utilizando la API REST (que describimos en el Capítulo 3), puedes estar realizando automatizaciones básicas de redes en muy poco tiempo. Para otros temas más avanzados, puede que necesites consultar referencias externas para comprender los lenguajes de programación que se utilizan. En este libro, utilizaremos mucho Python. Si no te sientes cómodo con Python, quizá quieras consultar otro libro que trate sobre Python, como Learning Python de Mark Lutz (O'Reilly).

Si estás muy familiarizado con la programación, te ayudaremos a aplicar tus conocimientos a Junos. Describiremos los métodos que puedes utilizar para automatizar con Junos, así como algunas de las herramientas, bibliotecas y protocolos que admiten estos métodos. Sin embargo, no trataremos en detalle los fundamentos de Junos. Para asegurarnos de que dispones de la información básica necesaria, en este capítulo cubrimos algunos de los fundamentos. Para obtener información adicional sobre Junos, puedes consultar alguna de las otras referencias que tienes a tu disposición. Por ejemplo, Day One: Junos Tips, Techniques, and Templates 2011, editado por Jonathan Looney et al. (Juniper Networks Books), contiene información que puede resultarte útil para familiarizarte con el software Junos.

Un consejo es que no sacrifiques lo bueno por lo perfecto. Hay muchas opciones de automatización, y hay muchas formas en que una red puede beneficiarse de la automatización. Te animamos a que elijas algo y empieces a utilizarlo para facilitarte las cosas. Si eres nuevo en programación, puede que la API REST te ofrezca una forma sencilla de empezar la automatización utilizando no mucho más que un script de shell. Si estás familiarizado con la programación pero eres nuevo en el software Junos, puede que la biblioteca PyEZ sea el punto de entrada más sencillo.

Otro consejo es que mantengas la mente abierta. Existen varias herramientas. Esto te proporciona la flexibilidad que necesitas para elegir la herramienta adecuada para la tarea adecuada. Es fácil tener visión de túnel y tratar de resolver todo de la misma manera. Sin embargo, no suele haber respuestas de "talla única" cuando se trata de automatización. Un script de commit puede ser la respuesta adecuada para un problema, mientras que un script de PyEZ puede ser la solución correcta para un problema diferente. Por tanto, lo mejor es conocer todas las herramientas y aplicarlas donde mejor convengan.

En la misma línea, conviene recordar que las herramientas se pueden combinar. Por ejemplo, puedes utilizar PyEZ para implementar una configuración y utilizar un script de confirmación para ampliar esa configuración. De este modo, las dos herramientas pueden trabajar juntas para producir la configuración que deseas.

Mientras lees el resto del libro, esperamos que te resulte útil conocer las formas en que puedes ahorrar tiempo, mejorar la eficacia, aumentar la precisión y facilitarte la vida automatizando tu red mediante el software Junos.

Get Automatizar la administración de Junos now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial