Ansible recently announced support for multi-vendor network modules, natively within Ansible. There are many examples on the Internet where individuals have taken the initiative to create their own modules to work with their favorite vendor. Some of these examples are Arista supplied modules, NX-OS modules – created by Jason Edelman, NTC, and NAPALM. While these are all good, it’s nice to see that Ansible is taking some initiative to create some native functionality.

These modules aren’t yet in the stable release of Ansible, but they do make an appearance in the development version, so I decided to kick the tires a bit.

First thing I did was set up an development environment using python’s virtualenv.

Shell

1

2

3

4

5

6

7

8

9

mkdir-pansible2.0/env

cdansible2.0

virtualenv env

source env/bin/activate

git clonegit@github.com:ansible/ansible.git

cdansible

git submodule init

git submodule update

python setup.pyinstall

Next, I verified the version of Ansible that I’m running in my development environment, as well as verifying that I have the new modules available to me.

At the time of this writing. It looks like the online documentation has been updated, which would infer that the new modules may soon be in the stable release.

So, let’s create a sample playbook!

The first thing I did was create an inventory file. I kept it simple and created a file called ‘hosts’

1

2

3

[ios]

edge1

aggr1a

Then I created a secrets.yaml file to store my credentials without having to put them in a playbook. While I won’t share my credentials here, I will share the format that I used. :)

YAML

1

2

3

4

5

---

creds:

username: cisco

password: cisco

auth_pass: cisco

Lastly, I created a sample playbook. I wanted a task that utilized each module type – (ios|eos|junos|nxos)_(command|template|config). Currently, I have easy access to a couple of IOS devices, so I stuck with using those modules, but I played with each ios_(command|config) module. I plan on spending time and playing with the ios_template module more at a later time.

Here is my sample playbook:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

---

-hosts:ios

gather_facts:no

connection:local

tasks:

-name:OBTAIN LOGIN CREDENTIALS

include_vars:secrets.yaml

-name:DEFINE PROVIDER

set_fact:

provider:

host:"{{ inventory_hostname }}"

username:"{{ creds['username'] }}"

password:"{{ creds['password'] }}"

auth_pass:"{{ creds['auth_pass'] }}"

-name:RUN'SHOW VERSION'

ios_command:

provider:"{{ provider }}"

commands:

-show version

register:version

-debug:var=version.stdout_lines

-name:RUN'SHOW ACCESS-LIST TEST'

ios_command:

provider:"{{ provider }}"

commands:

-show access-list TEST

register:before_acl

-debug:var=before_acl.stdout_lines

-name:CREATE'TEST'ACCESS-LIST

ios_config:

provider:"{{ provider }}"

authorize:yes

lines:

-10permit ip host1.1.1.1any

-20deny ip any any

parents:['ip access-list extended TEST']

before:['no ip access-list extended TEST']

match:exact

-name:RUN'SHOW ACCESS-LIST TEST'

ios_command:

provider:"{{ provider }}"

commands:

-show access-list TEST

register:after_acl

-debug:var=after_acl.stdout_lines

In this playbook, I first import my secrets.yaml variables, which includes my credentials to log into the devices. I then define the ‘provider’ variable. The provider variable allows you to create a host, username, password, and auth_pass key value in a single place and call it as a single variable, rather than defining each individually for each task. It’s a nice little time saver! Finally, I started doing work on the devices themselves.

PLAY RECAP *********************************************************************

aggr1a:ok=9changed=1unreachable=0failed=0

edge1:ok=9changed=1unreachable=0failed=0

As you can see, I was able to successfully execute a ‘show version’, verify that I had no access-list called TEST, create it, then verify that it was indeed created.

I’m thrilled that Ansible is finally getting around to recognizing the benefit of supporting the networking community. It’s a basic start and it will only get better from here! Soon, I’ll post a blog walking through the ios_template module. The documentation on that one looks interesting!

As a network engineer, a fundamental task is putting a base configuration onto a device via a serial console. In Windows, there are several applications from Hyper Terminal to Putty. In Linux, there is minicom. I’ve never been a Microsoft fan, but have been a Linux user for many years. Over the last few years have been using Mac OS X full time for work and personal. Given this, I need the ability to access a network device via a serial connection. A quick Google was fruitful.

Plug your USB to Serial device into the USB port.

Open a command termal and execute: ls /dev/*usb*

If your Mac recognizes the USB device, it will display a USB device in /dev. If not, you may need to download and install a USB driver for your device. I used this article to assist me in determining which USB driver to download and install.

My USB device showed up as /dev/tty.usbserial, thus I’ll use that for the remainder of this example.

Connect the other end of your USB to Serial cable into your network device’s serial port.

Execute: screen /dev/tty.usbserial 9600

Screen is a UNIX utility that allows you to access your local computers VT100 terminal.

/dev/tty.usbserial is the driver to access your USB serial device.

9600 is the baud rate.

Press enter and you should be prompted with your network device prompt.

To disconnect use the following key sequence: CTRL+A followed by CTRL+\