As promised, continuing with RESTCONF: A practical usage guide, let’s see how to convert to RESTCONF calls the rest of the CLI configurations used as example on that post. The method used to find this conversion was analyzed before and won’t be explained again here. So here you will find a compilation of the result of this conversion, with all the needed RESTCONF calls.
Let’s refresh the CLI commands of the example:
Tools needed
To work with RESTCONF, my tools are:
- Postman, to make HTTP requests to the boxes without having to write any script.
- Python3.6 with the “requests” library.
- Pyang, to explore YANG models
- A code editor, like Visual Studio Code for example.
- A lab with at least one device running IOS-XE. There are CSRv available on DevNet that can be used for this purpose.
Construction of the remaining requests
In the previous post, we had already found the base URI for the requests, using the “native” module:
https://<IP:Port>/restconf/data/Cisco-IOS-XE-native:nativeWe need to build the remaining URIs to complete the configuration. Also we need to define the body of the request messages. In order to do this, we are again going to divide the configuration in different building blocks. We see that is formed by six building blocks: keyring, IKEv2 auth policy, IKEv2 profile, IPSec profile, Loopback interfaces and Tunnel interface.
Block 1: Keyring
This block was already analyzed before, but I included it here for the sake of completion. The commands involved in this block are the following:
To configure this using RESTCONF, a POST request is used. Next, the URI and the request body:
POST https://<IP:Port>/restconf/data/Cisco-IOS-XE-native:native/crypto/ikev2Block 2: Auth Policy
The commands involved are the following:
You can see that in this case the configuration is being applied to the “default” policy. This means that the policy is already created on the device. If we do a GET request to the “native” module before applying any change we’re not going to see it because the policy is considered a default configuration. This has to be taken into account. The resource is not going to be created, but modified. Hence, we have to use the PUT method.
The method, URI and message body are:
PUT https://<IP:Puerto>/restconf/data/Cisco-IOS-XE-native:native/crypto/ikev2/authorizationNote: because a resource was modified, the resulting status code on the response is 204 (No Content). This is different from the one obtained as result when creating a resource using the POST method, which is 201 (Created).
Block 3: IKEv2 Profile
We create a new IKEv2 profile with the following code snippet:
The method, URI and message body are:
POST https://<IP:Port>/restconf/data/Cisco-IOS-XE-native:native/crypto/ikev2Block 4: IPsec Profile
We’re again modifying a default resource, as you can see on the following commands:
The method will be PUT, The URI and the message body are the following:
PUT https://<IP:Port>/restconf/data/Cisco-IOS-XE-native:native/crypto/crypto/ipsecBlock 5: Loopback Interface
The commands are the following:
Because it only creates an interface and assigns it an IP address, it is worth to leverage the standard IEFT modules. “ietf-interfaces” is the one that we need. In case that you want a little more practice on standard modules and interfaces, you can take advantage of this Devnet course.
The method, URI and message body are:
POST https://<IP:Port>/restconf/data/ietf-interfaces:interfacesBlock 6: Tunnel Interface
The commands are the following:
We don’t have in this case the possibility to use the standard module, so back to the “native” module! The method, URI and message body are:
POST https://<IP:Port>/restconf/data/Cisco-IOS-XE-native:native/interface/With this blocks we have finished the example configuration! Any doubt that you may have, please reach out to me using the comments section, or via email or Twitter.