Artículos anteriores han mostrado cómo maniobrar en torno a la jerarquía de la configuración de JunOS, y la forma en que los controles para la sintaxis correcta cada vez que se pulsa la barra espaciadora mientras se está tecleando una línea de configuración.

Pero hay momentos en que se puede teclear todas las líneas individuales de una configuración correctamente, y la configuración puede estar errónea. Es decir, la combinación de comandos no funcionan correctamente juntos o hay algo que falta entre las líneas.

En el siguiente ejemplo, se establece una muy simple configuración BGP. En primer lugar, nos vamos desde la parte superior de la jerarquía al grupo BGP Peering que se ha llamado External_Peer. No se ha tenido que utilizar el comando set para crear este grupo, sólo por entrar a este nivel, el grupo se crea solo. A continuación, se especifica un vecino en 172.16.1.5. Luego se especifica que el sistema autónomo vecino para el grupo es 65502. Por último, se precisa que una política de exportación llamada External_Peer_Policy se utiliza para modificar o filtrar las rutas enviada (exportadas) para el vecino. Una vez terminado, nos volvemos al raíz de la jerarquía de configuración.

En cada línea de configuración JunOS acepta las entradas, lo que indica que no se ha hecho ningún error (algo extraordinario):

[edit]
jeff@Juniper5# edit protocols bgp group External_Peer

[edit protocols bgp group External_Peer]
jeff@Juniper5# set neighbor 172.16.1.5

[edit protocols bgp group External_Peer]
jeff@Juniper5# set peer-as 65502

[edit protocols bgp group External_Peer]
jeff@Juniper5# set export External_Peer_Policy

[edit protocols bgp group External_Peer]
jeff@Juniper5# top

[edit]
jeff@Juniper5#

Pero cuando se intenta aplicar la configuración, JunOS se queja:

[edit]

jeff@Juniper5# commit
error: Policy error: Policy External_Peer_Policy referenced but not defined

[edit protocols bgp group External_Peer]
'export'
BGP: export list not applied
error: configuration check-out failed

[edit]
jeff@Juniper5#

Lo que trata de decir es que la política de exportación que se hace referencia en la configuración BGP no existe en ningún lugar de la configuración. (Se debe encontrar en algún lugar bajo [edit policy-options]).

Cuando el comando commit se ejecuta, JunOS ejecuta un conjunto de scripts que examinan la configuración candidata. Si se encuentra alguna situación, al igual que la que se mostra, en la que las diferentes líneas de la configuración no funcionan juntas, la aplicación de la configuración falla y aparece un mensaje de error que explica por qué ha fallado.

Por cierto, se puede usar el comando commit check que le dice a JunOS que ejecute los scripts contra la configuración candidato sin intentar aplicar la configuración. Eso es muy útil si estás añadiendo un montón de nuevas declaraciones a la configuración y quieres que los scripts comprueben de vez en cuando la configuración para ver como va.

Este tipo de comprobación de error de secuencias de comandos han sido añadido a JunOS desde su creación, y se basan en observar en la configuración incoherencias o de los que el equipo de desarrollo de JunOS puede anticipar.

Existe otro uso para este tipo de secuencias de comandos que va más allá de la comprobación de errores e incoherencias. El mismo tipo de scripts puede ser utilizado para verificar que la configuración se adhiere a las mejores prácticas. No obstante, ¿ cuales son las mejores prácticas ? Cada red es diferente, y las normas que establezca para su configuración podría ser diferente de las normas establecidas para ia configuración de otro.

No hay forma para los desarrolladores de JunOS de escribir scripts que cubran todas las posibles configuraciones de preferencia, por lo que en su lugar lo que se hizo fue algo radical y se abrió el editor para los usuarios de JunOS con la capacidad de ejecutar commit scripts.

Commit scripts le permite escribir sus propios scripts para el control de su configuración candidata cada vez que se ejecuta el comando commit. Estos scripts trabajan junto con los scripts de comprobación de error e incoherencia que se ejecutan cada vez que ejecuta commit, pero estos scripts están escritos para tu red, para asegurar no sólo que la configuración es correcta, sino que se adhiere a las normas que has diseñado para tu red:

Tal vez se requiere qie todos los operadores introduzcan una descripción en cada interfaz, proporcionar cierta información sobre la interfaz para el mantenimiento y solución de problemas de referencia. Puede escribir un commit script que haga eso.

Tal vez en su red, RSVP-TE debe correr en todas las interfaces SONET. Puede escribir un commit script que examine todos los interfaces SONET en el router y verifique que cada uno de ellos se contabilizan en el nivel de jerarquía de [edit protocols mpls].

Tal vez tu configuración requiere ciertas traceoptions (declaraciones similares al debug del IOS que recopilan información sobre el tráfico especificado o comportamientos y lo añade a un archivo) esten activadas a nivel global para BGP, otras traceoptions esten habilitadas para cada grupo de BGP peer, y aún otras traceoptions esten habilitadas para cada vecino en relación con cada grupo. Y se requiera que cada vecino tenga autenticación MD5. Puedes escribir un commit script para comprobar todo eso.

Un commit script puede ser tan simple como la comprobación para asegurarse de que cada configuración incluye su banner estándar de seguridad y que se mostrará cada vez que alguien haga login.

El punto es que los archivos de configuración tengan ciertas características y se organizen de una manera determinada. Se puede escribir un commit script personalizado que compruebe exactamente los parámetros que se especifique, y evitar que la configuración candidata se convierta en la configuración activa si la comprobación no tiene éxito.

Se puede escribir un commit script utilizando el Lenguaje Extensible de estilos de Transformación (XSLT) o la Sintaxis Alternativa de lenguaje de hoja de estilos (Slax) un lenguaje de script. Si un script que se ha creado se ejecuta y encuentra algo que ha considerado fuera de especificación, el script detendrá el commit y mostrará un mensaje de error o advertencia (también de tu especificación), o enviará un mensaje personalizado a un servidor syslog.

También se puede - y aquí es donde las cosas comienzan a ponerse interesantes - corregir el archivo de configuración para ponerlo en conformidad con tu configuración estándar. Esto se hace con una macro, y en este momento es donde emppezamos a ver el potencial de commit script: Configuraciones que sean incompatibles de un router a otro en tu red, o incluso incompatibles entre las distintas partes de la misma configuración, pueden ralentizar las operaciones personales al tratar de averiguar las diferentes configuraciones. Y son una fuente de errores ya que los operadores interpretan de manera errónea o simplemente se pierden algo que escribió otra persona fuera de norma.

Scripts de configuración se pueden utilizar para asegurar que cada una de tus configuraciones cumplen el 100% de las normas de su configuración, el 100% del tiempo.

---

Otro estupendo artículo de Jeff Doyle, la versión original aquí.