Val:~$ whoami

I am Val Glinskiy, network engineer specializing in data center networks. TIME magazine selected me as Person of the Year in 2006.

Search This Blog

Monday, December 15, 2014

Manage network devices with Ansible

Ansible is one of the best technologies we took from buggers after the war.  I loved "Ender's game" book, not the movie.
Inspired by excellent posts  by Kirk Byers I decided to try Ansible not only to generate configuration for network switches, but to make configuration changes. I have virtual Arista switch running in VirtualBox, so this is where I ran my tests, but it's easy to replicate with Juniper or Cisco Nexus switches. I used user "root", although any user with priviledge level 15 will do.
First, enable root user on Arista switch:
Arista-5#(conf) aaa root secret SecretPassword

Next step is to go to managemnent server and generate ssh key without password. Resulted public key should be added to /root/authorized_keys file on Arista switch.

Now, to Ansible.

My ansible.cfg:
[defaults]
host_key_checking=False
hostfile=/home/user1/ansible/hosts
log_path=~/ansible.log

Let's do very simple task: copy new OS image file and update boot variable. Here is my very simple playbook upgrade.yml:
---
- hosts: arista
  remote_user: root
  tasks:
  - name: Push image
     copy: src=/home/user1/Documents/ansible/vEOS-1.swi dest=/mnt/flash/vEOS-1.swi
  - name: Change boot variable
    command: FastCli -p15 -c "install source vEOS-1.swi now"


Really simple inventory file:
[arista]
arista-5

Let's run it:













It worked, boot variable now points to vEOS-1.swi file.



What happens if you you use RADIUS for authentication and have to enter 
password to log into your switch? In this case Ansible uses sshpass which stores your password in the memory. From sshpass man page:

It is close to impossible to securely store the password, and users of sshpass should consider whether ssh's public key authentication provides the same end-user experience, while involving less hassle and being more secure.


If you are willing to take this risk, insert "ask_pass=True" line into your ansible.cfg to be prompted for password or run ansible_playbook command with -k option.

Saturday, November 22, 2014

Before you finish your next automation script

An excellent article from Wall Street Journal about pitfalls of automation:


This philosophy traps people in a vicious cycle of de-skilling. By isolating them from hard work, it dulls their skills and increases the odds that they will make mistakes. When those mistakes happen, designers respond by seeking to further restrict people’s responsibilities—spurring a new round of de-skilling.

Something to consider when you hand over that new automation script to your network operations center.

Wednesday, November 19, 2014

Al-too-na! Al-too-na!

There is a lot of press these days about new Facebook datacenter and how it (almost) means death of Cisco-Juniper-Arista. Here are the questions:
Did somebody try to run multicast on white-box switch?
Where do you place Rendezvous Point in this network?
There is only handful of companies with Facebook- or Google-size network, but hundreds of companies requiring multicast support in their data center. Until white box switches learn to run IGMP/PIM/MSDP Cisco and Juniper will have plenty of customers with deep pockets.

Wednesday, June 18, 2014

Auto Provisioning

Network automation is hot topic lately and has been my favorite past time for quite a while. While vendors provided tools to make changes on the switches and routers - Cisco Works come to mind - getting initial configuration on the switch was still manual process. Network operators would come up with some kind of template in Excel or text file and then replace host name and management IP address. To get initial configuration on the switch, one would use copy/paste, a process prone to errors, or upload text file to the switch and copy it to startup-config or candidate configuration. Latter process required configured management IP address and default gateway.  In addition to that operators had to upgrade/downgrade operating system.
Fast forward to today's era of Chef/Puppet/Ansible/Other appropriated household word. Cisco came up with (and Arista duly replicated) Power-on Auto Provisioning for its Nexus switches, POAP for short. In DHCP option 67 you need to provide Python script name that switch will download and execute. Arista also supports Bash scripts. Cisco even provides a script that can upgrade NX-OS and download corresponding configuration file based on one of the following parameters: switch name, management interface MAC address, serial number or CDP neighbors. You can write your own script to generate configuration on the fly.
Juniper came up with somewhat catchier name - Zero Touch Provisioning. It does not allow you run scripts. Juniper touted Junos as first network operating system that allowed scripts long before Cisco came up with EEM. Also, you have to use DHCP vendor options to encode configuration file name and Junos image file name.  So, in your DHCP server you have to put something like this: 0x00306a696e7374616c6c2d7166782d332d31332e325835302d4431352e332d646f6d65737469
632d7369676e65642e74677a0111646e6a722d6c61622d716678312e636667. Not very informative. Juniper promised to implement SLAX script support in near future and abandon DHCP vendor option in favor of option 67. Python support might come later.

Wednesday, April 23, 2014

Python on Nexus

If you are relying on handy "cisco" python module on your Nexus 5500 or 6K switches - stop. Cisco made considerable changes in version 7.0(1)N1(1).
Here what it looked like in 6.0(2)N2(3):
switch# python
Python 2.7.2 (default, Nov 27 2012, 17:50:33)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Loaded cisco NxOS lib!
>>> import cisco
>>> dir(cisco)
['BGPSession', 'BufferDepthMonitor', 'CLI', 'CheckPortDiscards', 'CiscoSecret', 'CiscoSocket', 'Feature', 'History', 'IPv4ACL', 'IPv6ACL', 'Interface', 'Key', 'LineParser', 'MacAddressTable', 'OSPFSession', 'Routes', 'SectionParser', 'VRF', 'Vlan', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__', 'acl', 'bfd', 'bgp', 'buffer_depth_monitor', 'check_port_discards', 'cisco_secret', 'cisco_socket', 'cli', 'dhcp', 'eigrp', 'feature', 'get_global_vrf', 'get_valid_port', 'history', 'hsrp', 'interface', 'interface-vlan', 'key', 'lacp', 'line_parser', 'mac_address_table', 'md5sum', 'msdp', 'ospf', 'ospfv3', 'pim', 'private-vlan', 'ptp', 'rip', 'routes', 'scheduler', 'section_parser', 'set_global_vrf', 'show_queues', 'show_run', 'ssh', 'tacacs', 'telnet', 'transfer', 'udld', 'vlan', 'vpc', 'vrf', 'vrrp', 'vtp']
>>>

In 7.0(1)N1(1)
>>> import cisco
>>> dir(cisco)
['__doc__', '__name__', '__package__', 'cli', 'cli_execution_error', 'cli_syntax_error', 'clid', 'clip']

According to Cisco representative "Starting 7.0(1)N1(1), python interpreter on N6K has been modified to look like python interpreter on N7K."
WHY DID NOT THEY DO OTHER WAY AROUND: MODIFY PYTHON ON N7K TO MATCH N6K?