RestAPI and Automated Deployment Support

[isaacunifio]

Hello, 

We are currently migrating a customer to the CSR 1000v in AWS but are having issues automating the deployment. I found some conflicting documentation that first stated that the RestAPI wasn't available on the CSR1000v AMI but found that it in fact was when checking the AMI once it was booted and running. I wasn't however able to utilize the restapi without first logging in and creating a user since the CSR is booted and accessed initially using a key and the ec2-user. I was hoping for help answering the following questions: 

- Can a user be specified prior to booting the CSR 1000v for the first time so that the RestAPI can be accessed on first boot without requiring ssh login to manually create that user and if so how? 

- I saw that there was documentation with an example on how to achieve HA using EEM to perform a route change. One of the documents indicated it was using a helper linux vm to execute these route changes, the other document made it seem as though the EEM applet was actually performing the route table change without accessing a helper vm. Are there any aws api tools accessible on the CSR in TCL form or any other that would allow the CSR to send SNS messages to aws or other API calls natively  without the use of a linux helper vm?  

- The CSR 1000v document for openstack shows the ability to provide some running configuration modifications prior to first boot using the 

ovf-env.xml and or iosxe_config.txt. What if any properties can be specified to be applied to the running-config on boot of the CSR instance and how does one specify these properties? 

Thanks for any help in these matters. We have found the CSR to satisfy our requirements, just need to fit the CSR into our deployment stratagies. 

[James Schultz · Accepted solution]

These are a few very good questions, and the answers should definitely be added to our future guides and documents. In the meantime, I'll try to help out with as much detail here as I can... There is in fact a way to pre-configure the CSR on AWS during the first boot. AWS includes a feature called "UserData", which is a text field that can be supplied to an instance during provisioning. Linux VMs can use this blob of text to allow a user to execute a script during the first boot, or in the case of the CSR, we allow you to use it to inject IOS CLI commands during the first boot. This UserData field can be specified using all of the AWS provisioning tools, including the Portal, API, CLI, CloudFormation, etc.  The only real trick to this, is prepending each CLI line with a numeric index.  Here's an example of a text block you could supply as UserData to have the CSR boot with a username/password pre-configured:

ios-config-0001=username test123 privilege 15 password test123

If you need to add other commands, you can just increment the "ios-config-xxxx" number at the beginning of each line.  AWS does have a size limit of 16KB for the UserData string, so be mindful of that limitation.

You could also go a step further and use CloudFormation to provision the CSR along with any additional infrastructure elements, and the UserData field can be supplies in that scenario as well. I've attached a file to this post, which contains an example CloudFormation template.  You'll notice it includes the same bit of UserData to bootstrap the username/password for API access, and it also opens up the default API port in the AWS Security Group.

Ok on to the next question...

For the high availaibility feature, we no longer require the use of a helper VM.  The script that makes the AWS API call has been integrated into the CSR itself, so EEM can call it directly.  The following link will walk you through the correct steps of using EEM without the helper VM:

http://www.cisco.com/c/en/us/td/docs/solutions/Hybrid_Cloud/Intercloud/CSR/AWS/CSRAWS/CSRAWS_4.html

Hopefully all of this helps get you started with some new provisioning options. :)

[isaacunifio]

Hello James,

Thank you so much for your response. The UserData should facilitate my ability to create the user that will ultimately be used to interact with the RestAPI to perform the rest of the iOS configuration changes we need to make.

I just wanted to make sure of the following:

- I wanted to verify that the RestAPI is supported on the CSR 1000v AWS AMI and once I have created that user, I will be able to successfuly utilize the RestAPI to make further configuration changes? Though it appeared it was supported. I wanted to confirm that it was since I found conflicting documentation

- Also are any of the other AWS API calls available directly through the EEM other then the route table change? I was hoping to possibly use ones for delivering SNS messages regarding events via EEM. For instance if I have a tunnel lose connectivity to have EEM run an applet that would deliver an SNS message to AWS using the API. I know making that route table change requires communicating with the AWS API so I just wanted to know if there were other mechanisms available to the EEM applet for communicating with the AWS API.

[James Schultz · Accepted solution]

You're very welcome; I'm glad I was able to help out.

The REST API is absolutely supported on the CSR, in any environment AWS or otherwise.  Once you have the username and password configured, you should be good to go.

At the moment we don't have any additional AWS API calls that can be made via EEM.  The management container on the CSR doesn't have a full installation of the AWS CLI tools or anything like that for us to interact with.  The API calls required for the HA feature are simple Curl commands that just hit the correct API URLs to make the very simple route table change.

I'll certainly explore the opportunity of adding this sort of functionality in the future though.

[isaacunifio]

Am I able to make curl command calls?

[James Schultz]

Nope :)  It's all done under the covers as part of the management container hosted inside the CSR.  The SNS use case does make a lot of sense though, so I'll work on socializing it with the team here to see if it's something we could add in the future.

[isaacunifio]

Much appreciated. If you happen to get that implemented in the next 2 days let me know ;). Seriously though that would be awesome and as soon as that is available will certainly make our situation a lot cleaner. 

The SNS messages are important for working with things like Lambda functions to do different magic when problems occur that are possibly beyond the scope of what the CSR is able to handle or accomodate. 

Thanks again for your help and look forward to an update.