Install ansible in mac os

Ansible is mainly used for automize Linux/windows servers provisioning and operation, however from version 2.1 there is support module for network related devices.

In order to test it I have first install ansible in my mac:

There are several ways to install ansible, but the mostly common used on mac is homebrew an pip. Here is the comparision of both installation ways:

"pip is a packager for the python world – you should only ever be able to install python-things with it; homebrew is a package manager targetted at OSX; it doesn’t impose any restrictions onto what software you can install with it – since python is a subset of software.

installing things with brew will install them into /usr/local/;

installing things with pip will fetch packages from the Python Package Index, and it will install them in a place where your python interpreter will find them: either into your home directory (e.g. ~/.local/lib/python2.7/site-packages/) or in some global search-path of your python interpreter (e.g. /usr/local/lib/python2.7/dist-packages/)”

We will just explore the way to install ansible with homebrew:

1, install Xcode (C compiler) in order to use python
xcode-select –install

2, Install python using homebrew

brew install python


brew install python3

Actually, step 1 and 2 can be skipped because all new Mac OS X has python 2.7 installed already.

3, brew install ansible

After the installation we can find ansible is installed under /usr/local/bin/

mac-c02t6npagtfj:bin grayin$ ls ansible*

ansible ansible-doc ansible-pull

ansible-config ansible-galaxy ansible-vault

ansible-connection ansible-inventory

ansible-console ansible-playbook

notes: do “brew update” first before the installation to avoid any unexpected errors


Some concept used in SDN


The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs).


YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.


describes a REST-like protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF.


Copied from internet

“BGP-LS is an extension to Border Gateway Protocol (BGP) for distributing the network’s link-state (LS) topology model to external entities, such as the SDN controller. It has received a lot of attention because many SDN apps need this model.

The network’s link-state topology model consists of nodes (typically, but not limited to, routers) and links that connect these routers together. For each link, a set of attributes is also contained. These may include interface addresses, various metrics, and each link’s total and available bandwidth. This topology model is distributed among routers using one of the two prominent Interior Gateway Protocols (IGPs): ISIS (Intermediate System to Intermediate System) and OSPF (Open Shortest Path First) protocols.

The detailed link-state models of these two protocols are not identical. As a result, BGP-LS defines its own more abstract topology model and defines how to map these IGP models to its own model. As the network topology is discovered by the IGPs, the changes are reflected in the BGP-LS model as well and are also distributed using BGP-LS messages to any interested party, such as SDN controllers and apps. Note that the network devices themselves are not interested in learning the network topology this way, as they already participate in IGP and learn it firsthand.”


The Cisco Application Policy Infrastructure Controller (Cisco APIC) is the unifying point of automation and management for the Application Centric Infrastructure (ACI) fabric.

It use policy agent to translate polices into instructions.


The EEM(Embedded Event manager is a software component of cisco IOS, XR, and NX-OS makes life easier for administrators by tracking and classifying events that take place on a router and providing notification options for those events. EEM allows you to automate tasks, perform minor enhancements and create workarounds.
There are two independent pieces: Applets and Scripting
-> Applets are a collection of CLI commands
-> Scripts are actions coded up in TCL(interpreter language)

EEM uses event detectors and actions to provide notifications of those events:

EEM detectors can be:
1) SNMP:-Monitoring SNMP objects.
2) Syslog:-Responds to various syslog messages, allowing for matching on regular expressions.
3) Counter: Monitoring and responding to interface counter when cross threshold settings.
4) CLI events: Screening CLI input for a regular expression match.
5) None: This event detector is use to test EEM script/applet using “event manager run” command.
6) Timers :(Countdown, watchdog and CRON)
7) IP SLA and Netflows events.


.cloginrc is a file that contains login information for each devices that will be accessed via clogin. .cloginrc is normally located under /home/username.

Below is an example of .cloginrc file:

# comments are cool, as is whitespace
# clogin supports a number of add directives:
# password
# user
# userprompt
# userpassword
# passprompt
# method
# noenable
# enauser
# enableprompt
# autoenable
# cyphertype
# identity
# Details on each of these follows. Also see cloginrc(5).
# add password <router name glob> <vty passwd> <enable passwd>
# add user <router name glob> <username>
# The default user is $USER (i.e.: the user running clogin).
# add userprompt <router name glob> <username prompt>
# What the router prints to prompt for the username.
# Default: {“(Username|login|user name):”}
# add userpassword <router name glob> <user password>
# The password for user if different than the password set
# using ‘add password’.
# add passprompt <router name glob> <password prompt>
# What the router prints to prompt for the password.
# Default: {“(\[Pp]assword|passwd):”}
# add method <router name glob> {ssh} […]
# Defines, in order, which connection method(s) to use for a device
# from the set {ssh,telnet,rsh}. e.g.: add method * {ssh} {telnet} {rsh}
# will attempt ssh connection first. if ssh fails with connection
# refused (i.e.: not due to authentication failure), then try telnet,
# then rsh.
# Default: {telnet} {ssh}
# add noenable <router name glob> <1>
# equivalent of -noenable on the cmd line to not enable at login.
# add enableprompt <router name glob> <enable prompt>
# What the router prints to prompt for the enable password.
# Default: {“\[Pp]assword:”}
# add enauser <router name glob> <username>
# This is only needed if enable asks for a username and this
# username is different from what user is set to.
# add autoenable <router name glob> <1/0>
# This is used if you are automatically enabled by the login process.
# add cyphertype <router name glob> <ssh encryption type>
# Default is 3des.
# set ssh encryption type, dflt: 3des
# Newer SG300 don’t support cbc, add aes256-ctr
add cyphertype * {aes256-cbc,aes256-ctr}
# add identity <router name glob> <path to ssh identity file>
# Default is your default ssh identity.
# include <file>
# include a secondary .cloginrc file
# Note: The first match for a hostname takes precedence.

#add password sl-bb*-dc cow24
#add password sl-gw*-dc geeks
#add password sl* hank dog
#add password at* pete cow
#add password sdn* mujahid horse
#add password icm* peter
#add password * anything
#add user sl-gw*-dc twit
#add user sdn* sdn_auto
#add user sdn-bb* ops_eng
#add user * $env(USER)

# customer x
# these routers ask for a username and password. we automatically get
# enable access after successful authentication.
#add user * roger
#add password * {doger}
#add autoenable * 1

# customer y
# this is the normal cisco login. a password followed by and enable password.
# try ssh first, then rlogin.
#add password * {vector} {victor}
#add method * ssh rlogin

# customer z; they use ssh only.
#add user * shirley
#add password * {jive} {surely}
#add method * ssh

# the route-server’s do not provide enable access. cmdline -noenable
# equivalent.
#add noenable route-server* 1

# all our routers, i.e.: everything else
#add password * {clearance} {clarence}

# set ssh encryption type, dflt: 3des
#add cyphertype * {3des}

# set the username prompt to “router login:”
#add userprompt * {“router login:”}

# ssh identity for a juniper; used with jlogin
#add identity $env(HOME)/.ssh/juniper

# riverstone / enterasys / cabletron (rivlogin) example
# these boxes are ‘back-to-front’ from cisco (i.e., ask
# for vty password always, then tac+/radius if configured).
# vty password and last resort (enable) password for rivlogin
#add password rs3000 {vtypass} {lastresort}
# if using tac+ or radius login, include these lines
#add user rs3000 {monster}
#add userpassword rs3000 {scary}

# include non-ssh-capable switches (i.e. 3500XL, 2900XL and sth1-core1a)
include /local/rancid/.cloginrc-switchesnonsshcapable

## Firewalls, only ssh is allowed

add method firewallname* ssh
add user firewallname* username

add password firewallname* {password}


Using clogin to automate some boring stuff

In some cases we need do some boring stuff, for example, checking every devices to document hardware type, serier number; to backup configuraiton; doing the same tiny changes on each network devices. It is time-consuming too if you have massive similar devices that you have to login and check one by one. This type of works can be automated by using clogin plus some simple scripts.

According to the maual,  clogin is an expect(1) script to automate the process of logging into a Cisco router, Catalyst switch, Extreme switch, Juniper ERX/E-series, Procket Networks, or Redback router. There are complementary scripts for Alteon, Avocent (Cyclades), Bay Networks (nortel), ADC-kentrox EZ-T3 mux, Foundry, HP Procurve switches and Cisco AGMs, Hitachi routers, Juniper Networks, MRV optical switch, Mikrotik routers, Netscreen firewalls, Netscaler, Riverstone, Netopia, Cisco WLCs and Xirrus arrays.

clogin reads the .cloginrc file for its configuration, then connects and logs into each of the routers specified on the command line in the order listed. Command-line options exist to override some of the directives found in the .cloginrc configuration file.

Below are simple examples of how clogin works:

Example 1

We want to login to each devices and check its serier number.  Let us assume that we have 20 devices, all of them are Juniper EX switches. Indead of logining and checking every devices, we can do the following script in Linux:

  1. list all devices hostname into a file “switches”
  2.  run the following script: for i in `cat /tmp/switches`; do /local/rancid/bin/clogin -autoenable -c “show virtual-chassis” $i >> /tmp/switchessn; done
  3. trim “switchessn” file to remove noneed text if necessary. now we have a file that contain all serier number and hardware type of switches

Example 2

If we need find our root bridge for each vlans in a layer 2 networks. Below is the script that I learned:

  1. Run the the first step to get the bridge ID´s of all the switches listed int eh file swtiches.txt
    for i in `cat /tmp/switches.txt`; do /local/rancid/bin/clogin -autoenable -c "sh spanning-tree bridge \n\n end" $i > /tmp/$i; done
  2. Purge the documents from step 1 to only contan the isolated bridge-id for each switch
    for b in `cat /tmp/switches.txt`; do egrep -o -m 1 "[[:space:]][[:alnum:]]{1,4}\.[[:alnum:]]{1,4}\.[[:alnum:]]{1,4}[[:space:]]" /tmp/170390/$b > /tmp/access-bridge-id/bridge-id_$b.txt; done
  3. As step 3 to collect the “spanning-tree root-id” table from each swith in the switches.txt document
    for v in `cat /tmp/switches.txt`; do /local/rancid/bin/clogin -autoenable -c "sh spanning-tree root \n\n end" $v > /tmp/root-id/root-id_$v; done
  4. Collect all file names containing the access-switch bridge-id´s to one file for parsing during the last step:
    printf "%b\n" /tmp/170390/access-bridge-id/* > /tmp/170390/access-bridge-id/access-bridges.txt
  5. Finally extract all the entries from the previous steps to find out what VLAN´s each access-switch is root bridge for.
    for x in `cat /tmp/170390/access-bridge-id/access-bridges.txt`; do grep -f $x /tmp/170390/root-id/* >> /tmp/170390/final/final.txt ; done