26 Nov

Conditional parameter value in Ansible playbooks

Juniper automation with Ansible

Ansible playbook is just a list of tasks executed one by one in the order you define them in the playbook code. Using the conditional statements you may skip execution of some tasks, but there is one general rule that should apply to all playbooks you create – keep the number of tasks at the minimum.

Execution of each task takes time, and until you provide additional optimization, Ansible will establish the connection, perform an authentication process and then terminate the connection with a remote device. The longer this process takes, the more time you waste when you execute the playbook. It is a good practice to consolidate the tasks – if you need to perform multiple commands on a remote network device, you should define them as a parameter of one task instead of running them in separate tasks. In rare cases it may lead to unexpected problems like the one I described in my post Automated scripts can send commands faster than RP can process.

Sometimes you need to vary the value of an option provided to the task module. If you need to get an output of a CLI command on Juniper device, you will use the module junos_command which is part of standard Ansible library. Using the display parameter, you can specify if command output will be encoded in XML or JSON format. JSON is a more flexible format, but it is not a supported output format on older JunOS version. If you try to request it but the firmware does not support it your task, and the whole playbook will fail. Most of the developers will create two separate task and the conditional test to check version as a task with the when option. However, let me show you the other, not that well known, way.

Read More
05 Nov

Ansible can’t read some facts from Juniper devices

Juniper automation with Ansible

It is really amazing how fast Ansible is developed lately. Stable versions are released more often and contain more changes required by IT professionals. Many of them fill the gaps between two worlds – the developers and operations engineers. Unfortunately, some modules are not catching up as fast as they should which causes problems in developing simple tasks. I experienced such when I was working on playbook example required for my latest press articles for ‘IT Professional’ magazine. The default Ansible junos_facts module couldn’t correctly read JunOS version on some devices. Usually on devices running the older firmware release. This can be a real problem if some tasks execution depends on the firmware version on the router or switch.

Besides the official modules and lots of roles available on Ansible Galaxy repository many vendors developed their own modules and let them use for free. In many cases, it should be considered a better, more secure approach as long as the vendor repository is still maintained. In my situation it was the easiest workaround of my problem.

Read More
24 Sep

If you build containers Alpine Linux is your friend

This post is related to Docker and automation

Every container image must start from a parent image or base image (the scratch). The parent image is the image you base your image on. The base image is like a completely empty container you need to fill with content. But in most cases, you will use another image as a parent, and you want it to be as minimal as possible. The Alpine Linux is your friend – remember this name and use it as much as possible.

Read More
20 Aug

Run Jenkins in the ​container

Jenkins and Docker - flexible environment

The more you work with automation, the more you will like the containers. They fit and scale correctly in CI/CD model and can be easily managed. The whole infrastructure for automation should be flexible, easy to maintain and extendable – containers fit perfectly into this model. So why not start from putting Jenkins in the container?

Read More
15 Feb

Cisco ASA REST API – Part VI: Swift on iPhone

Another not planned chapter 🙂 If you remember from Cisco ASA REST API – Part II: How it’s really working? Cisco mentions in documentation about three programming languages – Perl, Python and JavaScript via node.js. They even provide examples of code for the URI and methods that are supported. But does it mean it’s closed list of languages where REST API can be used? Definitely not! Remember, it’s still using the URI same as in web browser and methods that are same as for web servers. So you can use any programming language you want.

Why Swift? Because I got bored one evening 🙂 Well, that’s partially true. I’ve heard good opinions about Swift language from professional developers. It’s now open language available for many platforms, not only Apple products. I also like to try new things and was curious if learning at least basics of new language by myself would be hard and how quick I can do that. Also Apple was very helpful because of nice tutorial from Apple Developers which show step by step how to use XCode, build application interface and connect code to objects. There are many examples on Internet, I think the hardest thing at the beginning was to understand some language semantic constructions and get familiar with API of system libraries. Also, if you ever start programming in Swift remember that current version is Swift 3.0, but many examples on the web are from older versions and won’t work without minor or major changes to the code.

So what was my concept of an application? Easy, I just wanted to get information about firmware version installed on ASA. But of course if you have idea of other apps then sky is the limit 😉

Read More

17 Jan

Cisco ASA REST API – Part V: Node.js, JavaScript and small HTTP server displaying ACL

I was not planning this chapter and putting away Perl for even a moment, but I have some talk with my VeriFone colleague on scripting, REST API and how creating web server which uses REST API back end to control certain parameters of firewall is not that easy and straightforward. We both have some programming and scripting experience but neither of us is a programmer. We both know more or less several programming languages but we are not proficient. But we both have (at least we thing we have) good fundamental knowledge about programming.

The topic circulated around web page that will let display and manipulate ACL entries on firewall in non-SDN data center. Feature quite simple that most independent firewall management platforms can do. The problem is that most of those applications are using CLI via SSH to send commands and parse output, that’s exactly how Cisco ASDM is working in example, but we wanted something maybe a little more flexible, reliable… We both agreed that JSON is flexible structure that should be easy to use. So how to write a comprehensive script?

Read More

09 Jan

Cisco ASA REST API – Part IV: Debugging REST API Agent

First published: 09/Jan/2017
Last update: 09/Jan/2017

In chapter Cisco ASA REST API – Part I: Getting started primary configuration for REST API has been done on firewalls then in chapter Cisco ASA REST API – Part III: Checking if prefix is directly connected first script in Perl has been created. Let’s now look at ways we can troubleshoot REST API calls and status on Cisco ASA. This may be crucial to detect cause of the problem. Troubleshooting requires command line access to firewall in enabled mode.

In this chapter I will use script I presented previously and also will execute some REST API methods using Firefox RESTClient extension mentioned if first chapter. Because output of debug can be extensive listings will contain only crucial parts.

Debugging REST API means checking particular component for errors or other logs that might be interested for us. Command execution require in first place declaration which component will be debugged.

asav-1# debug rest-api ?

agent Rest-API Agent
cli Rest-API cli handling
client Rest-API client request handling
daemon Rest-API debug/syslog handling
process Starting/Stopping of Rest-API Agent
token-auth Rest-API Token authentication

Read More

03 Jan

Cisco ASA REST API – Part III: Checking if prefix is directly connected

First published: 03/Jan/2017
Last update: 03/Jan/2017

It’s time to do some programming and really use REST API for something good. The first script will be used to check if specified prefix is directly connected to any of firewall interfaces. Script requires two arguiments: checked IP address and IP address of firewall. The execution of script will be as below

$ ./IfDirectlyConnected.pl
Usage: IfDirectlyConnected.pl [Checked IP Address] [Firewall Management IP]

At this demo script require IP addresses to be used and is not checking if arguments are IP addresses, just simply validating if two it’s executed with two arguments.

Please take a moment to look back to my post Cisco ASA REST API – Lab topology and programming language where I explained the topology of simulated network and presented IP addresses assigned to each device. Routing is configured and all subnets are reachable.

We will test te script on asav-1 firewall. The expected results are as follow:

$ ./IfDirectlyConnected.pl 10.0.12.5 172.16.1.51
Checking address 10.0.12.5 on firewall 172.16.1.51
RESULT: Destination route is directly connected

$ ./IfDirectlyConnected.pl 10.0.24.5 172.16.1.51
Checking address 10.0.24.5 on firewall 172.16.1.51
RESULT: Route in routing table but not directly connected

$ ./IfDirectlyConnected.pl 10.0.99.5 172.16.1.51
Checking address 10.0.99.5 on firewall 172.16.1.51
RESULT: Subnet not in routing table

Script is available on my GitHub

Read More

14 Nov

Cisco ASA REST API – Lab topology and programming language

First published: 31/Oct/2016
Last update: 31/Oct/2016
ASA REST API version: 1.2.2

Before we start using Cisco ASA REST API let’s get familiar with network topology that will be used in chapters.

screen-shot-2016-11-01-at-22-24-21

Whole simulation is run on Cisco VIRL installed as VMWare VM and is using included ASAv and lxc-sshd images. VIRL is cheap and provide us wide range of virtual devices we can choose from for our simulation. ASAv is running image 9.5(2)204 which has preinstalled ASDM 7.5(2) and REST API version  1.2.2.200.

For your convenience the topology and all scripts will be available on GitHub Repository

Read More

31 Oct

Cisco ASA REST API – Part II: How it’s really working?

First published: 31/Oct/2016
Last update: 31/Oct/2016
ASA REST API version: 1.3.2

In previous chapter we configured ASA to support REST API interface and executed simply query. It was nice to see something in action but let’s now think how it’s working and how we can use it.

Every operation you can do using REST API you can also execute via traditional CLI commands or simplifying your life a little by using ASDM. Many of parameters you can fetch using SNMP or from syslog. So is it just another way to manage your device? Answer is both yes and no. Yes, because it is way of managing the device. No, because using REST API you have to stop thinking that you configure service but you are programming it usually as a part of bigger script or application.

REST API on ASA

REST API on ASA side is small plugin loaded into device flash memory and then activated using CLI.

 

rest-api-diagram

Read More