Como prometí, a modo de continuación del post RESTCONF: Una guía práctica de uso vamos a ver el resto de la configuración usada a modo de ejemplo, realizada con peticiones RESTCONF.
El método usado para encontrar la forma de construir las peticiones se analiza en ese post, por lo que aquí solo hay una recopilación del resultado para todas las transacciones necesarias para configurar el ejemplo completo.
Para refrescar la memoria, el código a construir es el siguiente:
Herramientas utilizadas
Para trabajar con RESTCONF, mis herramientas de trabajo son:
- Postman, para realizar peticiones a los equipos sin tener que escribir scripts.
- Python3.6 con la librería “requests”.
- Pyang, para explorar los modelos de YANG
- Un editor de código, Visual Studio Code por ejemplo.
- Un laboratorio con al menos un equipo con IOS-XE. Se puede utilizar los CSRv disponibles en DevNet con este fin.
Construcción de las peticiones restantes
En el post anterior, ya se había encontrado la URI base para usar con las peticiones, usando el módulo “native”:
https://<IP:Puerto>/restconf/data/Cisco-IOS-XE-native:nativeDebemos construir el resto de las URIs para completar la configuración, y también definir qué pasarle en el cuerpo de los mensajes. Para esto, nuevamente vamos a dividir la configuración en bloques. Viendo la configuración sabemos que hay seis bloques: keyring, IKEv2 auth policy, IKEv2 profile, IPSec profile, interfaz Loopback e interfaz Tunnel.
Bloque 1: Keyring
Este bloque ya ha sido analizado anteriormente, pero para que la configuración quede completa. Los comandos que se configuran en este bloque son los siguientes:
Para generar esta misma configuración con RESTCONF se usa el método POST. A continuación la URI y el cuerpo del mensaje:
POST https://<IP:Puerto>/restconf/data/Cisco-IOS-XE-native:native/crypto/ikev2Bloque 2: Auth Policy
Los comandos correspondientes a este bloque son:
En este caso, puede verse que la configuración se realiza sobre la policy “default”. Esto significa que la policy está creada. Si hacemos una consulta al módulo “native” antes de modificar la política no va a aparecer ninguna información al respecto, ya que se considera configuración por defecto. Hay que tenerlo en cuenta, porque no vamos a crear el recurso sino que vamos a modificarlo: el método a usar es PUT.
El método, la URI y el cuerpo del mensaje son:
PUT https://<IP:Puerto>/restconf/data/Cisco-IOS-XE-native:native/crypto/ikev2/authorizationNota: como se modificó un recurso, el status code que trae la respuesta es 204 (No Content). Esto es diferente al obtenido al crear un recurso con el método POST, donde obteníamos 201 (Created) como resultado de una operación correcta.
Bloque 3: IKEv2 Profile
Creamos un nuevo perfil para IKEv2 con la siguiente porción de código:
El método, la URI y el cuerpo del mensaje son:
POST https://<IP:Puerto>/restconf/data/Cisco-IOS-XE-native:native/crypto/ikev2Bloque 4: IPsec Profile
Nuevamente estamos modificando un recurso creado por defecto, como se puede ver en el bloque de configuración:
La operación será PUT. La URI y el cuerpo del mensaje a continuación:
PUT https://<IP:Puerto>/restconf/data/Cisco-IOS-XE-native:native/crypto/crypto/ipsecBloque 5: Interfaz Loopback
Los comandos a cargar son los siguientes:
Ya que sólo implica crear una interfaz y configurarle una dirección IP, vale la pena aprovechar y usar módulos estándar de la IETF. “ietf-interfaces” es el que necesitamos. Si se necesita un poco más de práctica con interfaces y módulos estándar, en Devnet está este curso.
El método, la URI y el cuerpo del mensaje son:
POST https://<IP:Puerto>/restconf/data/ietf-interfaces:interfacesBloque 6: Interfaz Tunnel
Los comandos a configurar son los siguentes:
En este caso no podemos usar un módulo estándar, así que volvemos al módulo “native”. El método, la URI y el cuerpo del mensaje son:
¡Con esto terminamos la configuración de ejemplo! Cualquier duda, los invito a dejármela en los comentarios, mail o vía Twitter.