Use Postman to configure CSR1000v router on Cisco Sandbox with RESTCONF

5 min read

Both Postman and RESTCONF show up as topics on the ENCOR exam, and the best way to really understand them is to actually drive a real router through a REST API rather than just reading about it. This walkthrough uses Postman together with a free, Cisco-hosted CSR1000v router on the Cisco DevNet Sandbox to do exactly that. Before starting, Postman itself needs to be installed.

1. Import the Cisco IOS-XE Postman Collection

Cisco DevNet publishes a ready-made Postman collection (in Collection v2.1 format) containing pre-built RESTCONF requests for IOS-XE devices. Exporting that collection and then importing it into your own Postman gives you a working set of requests to start from, instead of building every request from scratch.

Exporting the Cisco DevNet IOS-XE collection from Postman.

Selecting the Collection v2.1 format when exporting.

Starting the import of the collection file into your own Postman.

Uploading the exported collection file.

The collection now appears in Postman, ready to use.

2. Choose a Sandbox Device

Rather than needing a physical or virtual router of your own, Cisco provides free, pre-configured devices through the DevNet Sandbox at devnetsandbox.cisco.com/RM/Topology. Searching for “IOS XE” there surfaces the “IOS XE on CSR Latest” Always-On lab, which is available around the clock without needing to be reserved. This sandbox page provides the device’s hostname (sandbox-iosxe-recomm-1.cisco.com) along with its login credentials and port information.

Searching the DevNet Sandbox catalog for an IOS XE lab.

The Always-On sandbox lab page, showing the host and connection details.

3. Configure Authentication

Rather than entering credentials separately on every single request, it’s much simpler to set Basic Auth once at the collection level, using the username and password provided by the sandbox, and then set each individual request (and any subfolders) to “Inherit auth from parent.” This way, every request in the collection automatically uses the same credentials without having to repeat them.

Configuring Basic Auth once, at the collection level.

Entering the sandbox device’s credentials.

Setting a request to inherit authentication from the collection.

4. Define Environment Variables

The imported collection’s requests reference variables like {{host}} rather than hardcoding an address, so a Postman environment has to be created to supply actual values for them. Creating an environment named “Cisco IOS XE” with a host variable set to the sandbox’s hostname, and a port variable set to the sandbox’s RESTCONF port, lets {{host}} and {{port}} resolve correctly wherever they appear in a request’s URL.

Before the environment is configured, variables like host and port are unresolved.

Postman flags a variable it cannot resolve to any environment value.

Creating a new environment named “Cisco IOS XE.”

Selecting the new environment so its variables become active.

Setting the host variable to the sandbox device’s hostname.

Setting the port variable to the sandbox device’s RESTCONF port.

5. Save a Request

With auth inheritance and variables both set up, each request should be saved so these settings stick for future use.

Saving the request once authentication and variables are configured.

6. Send a GET Request

A GET request against the router’s interface data behaves much like running a show command on the CLI — it simply retrieves current state without changing anything. A successful GET should return an HTTP 200 OK status along with the interface information in the response body.

A successful GET request, returning HTTP 200 OK with interface data.

Troubleshooting: SSL Certificate Errors

If Postman reports an SSL certificate verification error when talking to the sandbox device, it’s typically because the device’s certificate isn’t trusted by Postman’s default settings. This is resolved by disabling SSL certificate verification under Postman’s own settings.

An SSL certificate error, resolved by disabling SSL verification in Postman’s settings.

7. Create a Loopback Interface with POST

To create something new on the router — in this case, a Loopback interface — a POST request is used instead of GET. First, the request’s URL needs to be changed from http to https, since the sandbox’s RESTCONF endpoint requires a secure connection. The request body then supplies the new interface’s details: a name of Loopback101, an IP address of 143.1.1.1, and a netmask of 255.255.255.0. A successful POST returns HTTP 201 Created, confirming the new interface was added.

Switching the request’s URL scheme to https before sending a POST.

A POST request creating a new Loopback101 interface with the specified IP and netmask.

8. Delete a Loopback Interface with DELETE

Removing the interface again is just as straightforward: appending the interface’s name, “Loopback101,” to the end of the request URL and sending a DELETE request removes it from the router. A successful DELETE returns HTTP 204 No Content, since there’s no body to return once the resource is gone.

A DELETE request removing the Loopback101 interface, returning 204 No Content.

Summary of Status Codes

Across all of these examples, any status code in the 2xx range indicates success: 200 for a successful GET, 201 when a new resource like Loopback101 is created, and 204 when a resource is deleted and there’s nothing further to return in the response body.