Carga de archivos de configuración
La carga de archivos de configuración en el dispositivo es útil para cargar partes de archivos de configuración que pueden ser comunes en muchos dispositivos dentro de una red.
Ejemplos para cargar una configuración desde un archivo o el terminal
Puede crear un archivo que contenga datos de configuración para un dispositivo de Juniper Networks, copiar el archivo en el dispositivo local y, a continuación, cargar el archivo en la CLI. Después de cargar el archivo, puede confirmarlo para activar la configuración en el dispositivo o puede editar la configuración de forma interactiva mediante la CLI y confirmar la configuración más adelante.
También puede crear una configuración mientras escribe en el terminal y, a continuación, cargar la configuración. Cargar una configuración desde el terminal es útil cuando se cortan partes existentes de la configuración y se pegan en otra parte de la configuración.
Para cargar un archivo de configuración existente que se encuentra en el dispositivo, utilice el comando de load
modo de configuración:
[edit] user@host# load (factory-default | merge | override | patch | replace | set | update) filename <relative> <json>
Para cargar una configuración desde el terminal, utilice la siguiente versión del comando de load
modo de configuración. Presione Ctrl-d para finalizar la entrada.
[edit] user@host# load (factory-default | merge | override | patch | replace | set | update) terminal <relative> <json>
Para reemplazar una configuración completa, especifique la override
opción en cualquier nivel de la jerarquía. Una load override
operación reemplaza completamente la configuración candidata actual con el archivo que está cargando. Por lo tanto, si guardó una configuración completa, utilice esta opción.
Una operación descarta override
la configuración candidata actual y carga la configuración en filename o la configuración que escriba en el terminal. Cuando se utiliza la override
opción y se confirma la configuración, todos los procesos del sistema reanalizan la configuración.
Para reemplazar partes de una configuración, especifique la replace
opción. La load replace
operación busca replace:
las etiquetas que agregó al archivo cargado. A continuación, la operación reemplaza esas partes de la configuración candidata con lo que se especifique después de la etiqueta. Esto es útil cuando desea tener más control sobre exactamente lo que se está cambiando. Para que esta operación funcione, debe incluir replace:
etiquetas en el archivo o configuración que escriba en el terminal. El software busca las replace:
etiquetas, elimina las instrucciones existentes del mismo nombre, si las hay, y las reemplaza con la configuración entrante. Si no existe ninguna instrucción del mismo nombre, la replace
operación agrega a la configuración las instrucciones marcadas con la replace:
etiqueta.
Si, en una override
operación o merge
, especifica un archivo o texto de tipo que contiene replace:
etiquetas, las replace:
etiquetas se omiten. En este escenario, la override
operación o merge
tiene prioridad y se realiza.
Si está realizando una replace
operación y el archivo que especifica carece de replace:
etiquetas, la replace
operación se ejecuta como una merge
operación. La replace
operación también se ejecuta como una merge
operación si el texto que escribe carece de replace:
etiquetas. Esta información puede ser útil si está ejecutando secuencias de comandos automatizadas y no puede saber de antemano si las secuencias de comandos necesitan realizar una replace
operación o una merge
operación. Los scripts pueden usar la replace
operación para cubrir cualquiera de los casos.
La load merge
operación combina la configuración del archivo o terminal guardado con la configuración candidata existente. Esta información es útil si va a agregar nuevas secciones de configuración. Por ejemplo, supongamos que está agregando una configuración de BGP al nivel de [edit protocols]
jerarquía, donde antes no había ninguna configuración de BGP. Puede utilizar la load merge
operación para combinar la configuración entrante con la configuración candidata existente. Si la configuración existente y la configuración entrante contienen instrucciones contradictorias, las instrucciones de la configuración entrante invalidan las de la configuración existente.
Para reemplazar solo las partes de la configuración que han cambiado, especifique la update
opción en cualquier nivel de la jerarquía. La load update
operación compara la configuración candidata y los nuevos datos de configuración. Esta operación cambia sólo aquellas partes de la configuración candidata que son diferentes de la nueva configuración. Utilizaría esta operación, por ejemplo, si existe una configuración de BGP y el archivo que está cargando la cambia de alguna manera.
Las merge
opciones , override
, y update
admiten cargar datos de configuración en formato de notación de objetos JavaScript (JSON). Al cargar datos de configuración que utilicen formato JSON, debe especificar la json
opción en el comando. Para cargar datos de configuración JSON que contengan entradas de lista desordenadas, es decir, entradas de lista en las que la clave de lista no es necesariamente el primer elemento de la entrada de lista, consulte Cargar datos de configuración JSON con entradas de lista desordenadas.
Para cambiar parte de la configuración con un archivo de revisión, especifique la patch
opción. La load patch
operación carga un archivo o entrada de terminal que contiene cambios de configuración. En primer lugar, en un dispositivo que ya tenga los cambios de configuración, escriba el show | compare
comando para generar las diferencias entre dos configuraciones. Luego puede cargar las diferencias en otro dispositivo. La ventaja del load patch
comando es que le ahorra tener que copiar fragmentos de diferentes niveles de jerarquía en un archivo de texto antes de cargarlos en el dispositivo de destino. Esto puede ser un ahorro de tiempo útil si está configurando varios dispositivos con las mismas opciones. Por ejemplo, supongamos que configura una directiva de enrutamiento en el enrutador1 y desea replicar la configuración de directiva en el enrutador 2, el enrutador 3 y el enrutador 4. Puede utilizar la load patch
operación.
En este ejemplo, primero se ejecuta el show | compare
comando.
Ejemplo:
user@router1# show | compare rollback 3 [edit protocols ospf] + export default-static; - export static-default [edit policy-options] + policy-statement default-static { + from protocol static; + then accept; + }
Continuando con este ejemplo, copie el show | compare
resultado del comando en el portapapeles, asegurándose de incluir los niveles de jerarquía. En el enrutador 2, enrutador 3 y enrutador 4, escriba load patch terminal
y pegue el resultado. A continuación, presione Entrar y presione Ctrl-d para finalizar la operación. Si la entrada de revisión especifica valores diferentes para una instrucción existente, la entrada de revisión reemplaza la instrucción existente.
Para utilizar la merge
opción , replace
, set
o update
sin especificar el nivel de jerarquía completo, especifique la relative
opción. Esta opción carga la configuración entrante en relación con el punto de edición actual en la jerarquía de configuración.
Ejemplo:
[edit system]
user@host# show static-host-mapping
bob sysid 987.654.321ab
[edit system]
user@host# load replace terminal relative
[Type ^D at a new line to end input]
replace: static-host-mapping {
bob sysid 0123.456.789bc;
}
load complete
[edit system]
user@host# show static-host-mapping
bob sysid 0123.456.789bc;
Para cargar una configuración que contenga set
comandos de modo de configuración, especifique la set
opción. Esta opción ejecuta las instrucciones de configuración línea por línea a medida que se almacenan en un archivo o desde un terminal. Las instrucciones pueden contener cualquier comando de modo de configuración, como set
, exit
edit
, , y top
.
Para copiar un archivo de configuración de otro sistema de red al enrutador local, puede usar las utilidades SSH y Telnet, tal como se describe en el Explorador de CLI.
Si trabaja en un entorno de Common Criteria, los mensajes de registro del sistema se crean cada vez que se cambia un secret
atributo (por ejemplo, cambios de contraseña o cambios en el secreto compartido de RADIUS). Estos cambios se registran durante las siguientes operaciones de carga de configuración:
load merge load replace load override load update
Cómo funciona la codificación de caracteres en dispositivos de Juniper Networks
Los datos de configuración de Junos OS y la salida del comando operativo pueden contener caracteres que no sean ASCII, que están fuera del juego de caracteres ASCII de 7 bits. Cuando se muestran datos operativos o de configuración en ciertos formatos o dentro de un cierto tipo de sesión, el software escapa y codifica estos caracteres. El software escapa o codifica los caracteres utilizando la referencia de caracteres decimales UTF-8 equivalente.
La CLI intenta mostrar cualquier carácter que no sea ASCII en los datos de configuración que se generan en formato texto, set o JSON. La CLI también intenta mostrar estos caracteres en la salida de comandos que se genera en formato de texto. En los casos de excepción, la CLI muestra la referencia de caracteres decimales UTF-8 en su lugar. (Los casos de excepción incluyen datos de configuración en formato XML y salida de comandos en formato XML o JSON). En las sesiones de protocolo XML de NETCONF y Junos, verá un resultado similar si solicita datos de configuración o salida de comandos que contengan caracteres que no sean ASCII. En este caso, el servidor devuelve la referencia de caracteres decimales UTF-8 equivalente para esos caracteres para todos los formatos.
Por ejemplo, supongamos que la siguiente cuenta de usuario, que contiene la letra minúscula latina n con una tilde (ñ), está configurada en el dispositivo.
[edit] user@host# set system login user mariap class super-user uid 2007 full-name "Maria Peña"
Cuando se muestra la configuración resultante en formato de texto, la CLI imprime el carácter correspondiente.
[edit] user@host# show system login user mariap full-name "Maria Peña"; uid 2007; class super-user;
Cuando se muestra la configuración resultante en formato XML en la CLI, el carácter ñ se asigna a su referencia ñ
de caracteres decimales UTF-8 equivalente. El mismo resultado se produce si muestra la configuración en cualquier formato en una sesión de protocolo NETCONF o Junos XML.
[edit] user@host# show system login user mariap | display xml <rpc-reply xmlns:junos="http://xml.juniper.net/junos/17.2R1/junos"> <configuration junos:changed-seconds="1494033077" junos:changed-localtime="2017-05-05 18:11:17 PDT"> <system> <login> <user> <name>mariap</name> <full-name>Maria Peña</full-name> <uid>2007</uid> <class>super-user</class> </user> </login> </system> </configuration> <cli> <banner>[edit]</banner> </cli> </rpc-reply>
Cuando cargue datos de configuración en un dispositivo, puede cargar caracteres que no sean ASCII utilizando sus referencias de caracteres decimales UTF-8 equivalentes.
Acerca de la especificación de instrucciones e identificadores
En este tema se proporcionan detalles sobre las instrucciones contenedor CLI y las instrucciones leaf para que sepa cómo especificarlas al crear archivos de configuración ASCII. En este tema también se describe cómo la CLI realiza la comprobación de tipos para comprobar que los datos introducidos tienen el formato correcto.
Especificación de instrucciones
Las instrucciones se muestran de dos maneras, ya sea con llaves ({ }) o sin:
-
Nombre e identificador de la instrucción, con una o más instrucciones de nivel inferior encerradas entre llaves:
statement-name1 identifier-name { statement-name2; additional-statements; }
-
Nombre de la instrucción, identificador y un identificador único:
statement-name identifier-name1 identifier-name2;
El statement-name es el nombre de la instrucción. The identifier-name es un nombre u otra cadena que identifica de forma exclusiva una instancia de una instrucción. Se utiliza un identificador cuando se puede especificar una instrucción más de una vez en una configuración.
Al especificar una instrucción, debe especificar un nombre de instrucción, un nombre de identificador o ambos, dependiendo de la jerarquía de la instrucción.
Los identificadores se especifican de una de las maneras siguientes:
-
identifier-name: es identifier-name una palabra clave que se utiliza para identificar de forma exclusiva una instrucción cuando una instrucción se puede especificar más de una vez en una instrucción.
-
identifier-name value: la identifier-name es una palabra clave y la value es una variable de opción obligatoria.
-
identifier-name [value1 value2 value3
...]
—La identifier-name es una palabra clave que acepta varios valores. Los corchetes son necesarios cuando se especifica un conjunto de valores; Sin embargo, son opcionales cuando se especifica un solo valor.
Los ejemplos siguientes ilustran cómo se especifican las instrucciones y los identificadores en la configuración:
protocol { # Top-level statement (statement-name). ospf { # Statement under "protocol" (statement-name). area 0.0.0.0 { # OSPF area "0.0.0.0" (statement-name identifier-name), interface so-0/0/0 { # which contains an interface named "so-0/0/0." hello-interval 25; # Identifier and value (identifier-name value). priority 2; # Identifier and value (identifier-name value). disable; # Flag identifier (identifier-name). } interface so-0/0/1; # Another instance of "interface," named so-0/0/1, } # this instance contains no data, so no braces } # are displayed. } policy-options { # Top-level statement (statement-name). term term1 { # Statement under "policy-options" # (statement-name value). from { # Statement under "term" (statement-name). route-filter 10.0.0.0/8 orlonger reject; # One identifier ("route-filter") with route-filter 127.0.0.0/8 orlonger reject; # multiple values. route-filter 128.0.0.0/16 orlonger reject; route-filter 149.20.64.0/24 orlonger reject; route-filter 172.16.0.0/12 orlonger reject; route-filter 191.255.0.0/16 orlonger reject; } then { # Statement under "term" (statement-name). next term; # Identifier (identifier-name). } } }
Cuando se crea un archivo de configuración ASCII, se especifican instrucciones e identificadores. Cada instrucción tiene un estilo preferido y la CLI utiliza ese estilo cuando muestra la configuración en respuesta a un comando de modo de configuración show
. Puede especificar instrucciones e identificadores de una de las siguientes maneras:
-
Instrucción seguida de identificadores:
statement-name identifier-name [...] identifier-name value [...];
-
Instrucción seguida de identificadores entre llaves:
statement-name { identifier-name; [...] identifier-name value; [...] }
-
Para algunos identificadores repetitivos, puede utilizar un conjunto de llaves para todas las instrucciones:
statement-name { identifier-name value1; identifier-name value2; }
Realización de la comprobación de tipos de CLI
Cuando se especifican identificadores y valores, la CLI realiza una comprobación de tipos para comprobar que los datos introducidos tienen el formato correcto. Por ejemplo, para una instrucción en la que debe especificar una dirección IP, la CLI requiere que escriba una dirección en un formato válido. De lo contrario, un mensaje de error indica lo que debe escribir. enumera los tipos de datos que comprueba la CLI. Los siguientes son tipos de entrada de configuración de CLI:
Tipo de dato |
Formato |
Ejemplos |
---|---|---|
Nombre de interfaz física (utilizado en la jerarquía [ |
|
Correct: Incorrect: |
Nombre completo de la interfaz |
|
Correct: Incorrect: |
Nombre de interfaz completo o abreviado (usado en lugares distintos de la jerarquía [ |
|
Correct: |
Dirección IP |
|
Correct: Sample translations:
|
Dirección IP (prefijo de destino) y longitud del prefijo |
|
Correct: Sample translations:
|
Dirección de la Organización Internacional de Normalización (ISO) |
|
Correct: Sample translations:
|
Identificador de área (ID) de OSPF |
|
Correct: Sample translations:
|
Acerca de la carga de una configuración desde un archivo
En los ejemplos siguientes se muestra el proceso de carga de una configuración desde un archivo.
Cargar un archivo de configuración
Puede crear un archivo de configuración en el sistema local, copiar el archivo en el dispositivo y, a continuación, cargar el archivo en la CLI. Después de cargar el archivo de configuración, puede confirmarlo para activar la configuración en el dispositivo. También puede editar la configuración de forma interactiva mediante la CLI y confirmarla más adelante.
Para cargar un archivo de configuración desde el sistema local:
Para ver los resultados de los pasos de configuración antes de confirmar la configuración, escriba el show
comando en el símbolo del usuario.
Para confirmar estos cambios en la configuración activa, escriba el commit
comando en el símbolo del usuario. También puede editar la configuración de forma interactiva mediante la CLI y confirmarla más adelante.
Cargar datos de configuración JSON con entradas de lista desordenadas
El esquema de Junos define determinados objetos de configuración como listas. En los datos de configuración JSON, una instancia de lista se codifica como un par nombre/matriz y los elementos de matriz son objetos JSON. Generalmente, el orden de los miembros en una entrada de lista codificada en JSON es arbitrario porque los objetos JSON son fundamentalmente colecciones desordenadas de miembros. Sin embargo, el esquema de Junos requiere que las claves de lista precedan a cualquier otro elemento relacionado dentro de una entrada de lista y aparezcan en el orden especificado por el esquema.
Por ejemplo, el user
objeto en el nivel de [edit system login]
jerarquía es una lista donde name
es la clave de lista que identifica de forma exclusiva a cada usuario.
list user { key name; description "Username"; uses login-user-object; }
En los siguientes datos de configuración de ejemplo, la clave de lista (name
) es el primer elemento para cada usuario. De forma predeterminada, al cargar datos de configuración JSON, los dispositivos Junos requieren que las claves de lista precedan a cualquier otro elemento del mismo nivel dentro de una entrada de lista y aparezcan en el orden especificado por el esquema.
{ "configuration" : { "system" : { "login" : { "user" : [ { "name" : "operator", "class" : "operator", "uid" : 3001 }, { "name" : "security-admin", "class" : "super-user", "uid" : 3002 } ] } } } }
Los dispositivos Junos ofrecen dos opciones para cargar datos de configuración JSON que contienen entradas de lista desordenadas, es decir, entradas de lista en las que la clave de lista no es necesariamente el primer elemento.
-
Utilice el comando de
request system convert-json-configuration
modo operativo para generar datos de configuración JSON con entradas de lista ordenadas antes de cargar los datos en el dispositivo. -
Configure la
reorder-list-keys
instrucción en el nivel jerárquico[edit system configuration input format json]
. Después de configurar la instrucción, puede cargar datos de configuración JSON con entradas de lista desordenadas y el dispositivo reordena las claves de lista según lo requiera el esquema de Junos durante la operación de carga.
Al configurar la reorder-list-keys
instrucción, la operación de carga puede tardar mucho más en analizar la configuración, dependiendo del tamaño de la configuración y del número de listas. Por lo tanto, para configuraciones grandes o configuraciones con muchas listas, recomendamos usar el request system convert-json-configuration
comando en lugar de la reorder-list-keys
instrucción.
Por ejemplo, supongamos que el user-data.json
archivo contiene la siguiente configuración JSON. Si intentó cargar la configuración, el dispositivo emitiría un error de carga porque admin2
la clave name
de lista no es el primer elemento de esa entrada de lista.
user@host> file show /var/tmp/user-data.json { "configuration" : { "system" : { "login" : { "user" : [ { "name" : "admin1", "class" : "super-user", "uid" : 3003 }, { "class" : "super-user", "name" : "admin2", "uid" : 3004 } ] } } } }
Si utiliza el request system convert-json-configuration
comando con el archivo anterior como entrada, el comando genera el archivo de salida especificado con datos de configuración JSON que el dispositivo Junos puede analizar durante la operación de carga.
user@host> request system convert-json-configuration /var/tmp/user-data.json output-filename user-data-ordered.json user@host> file show user-data-ordered.json { "configuration":{ "system":{ "login":{ "user":[ { "name":"admin1", "class":"super-user", "uid":3003 }, { "name":"admin2", "class":"super-user", "uid":3004 } ] } } } }
Como alternativa, puede configurar la instrucción de reorder-list-keys
configuración.
user@host# set system configuration input format json reorder-list-keys user@host# commit
Después de configurar la instrucción, puede cargar el archivo de configuración JSON original con entradas de lista desordenadas y el dispositivo controla las entradas de lista cuando analiza la configuración.
user@host# load merge json /var/tmp/user-data.json load complete