Showing posts with label Arista Networks. Show all posts
Showing posts with label Arista Networks. Show all posts

Tuesday, August 27, 2013

Arista Networks vEOS and eAPI

It has been a few months since I worked on Arista switches. Recently I received a copy of vEOS from the Arista Account Manager (Thanks! Mike) in the region, also around the same time I saw a post by Mark Berly on eAPI. The vEOS build is 4.12.1, several releases newer than the last version I worked on so I have decided to see if I can test drive the eAPI on the vEOS.

The steps I took are listed below. I have to say I am pretty impress with the combination. This allows network engineers to quickly try, test, and deploy scripts to quickly gather information from switches in production. The only drawback at this time is that not all CLI commands are supported, but this should be less of an issue as the API matures.

Here are the steps I took. Basically 1. Get vEOS online, 2. Enable eAPI, 3. Use Python to enable query.

Step 1. Download Aboot and vEOS disk image.

Here is the instruction link by Andre Pech: https://eos.aristanetworks.com/2011/11/running-eos-in-a-vm/. If you want to test eAPI like I did, make sure you download the 4.12.3 image (at the bottom of the page). If this is your first time, make sure you read the instruction on creating vmx file and change the path / version accordingly.

Step 2. Create the vmx file.

As indicated by the instruction, create the .vmx file and change the displayName and the paths to Aboot and Flash image. If you use a different version than the one listed in the file, don't forget to change that as well (such as EOS 4.12.3).
 9 displayName = "vEOS"
 55
 56 # Boot loader
 57 ide0:0.present = "TRUE"
 58 ide0:0.fileName = "<your path>/Aboot-veos-2.0.8.iso"
 59 ide0:0.deviceType = "cdrom-image"
 60
 61 # Internal flash
 62 ide0:1.present = "TRUE"
 63 ide0:1.fileName = "<your path>/EOS-4.12.3-veos.vmdk"
 64 ide0:1.redo = ""
 65
For me, I put the vmx file in the same directory as the aboot and flash disk image for management, but still specify full path. VMWare Fusion is installed on my Mac and double click the file will open the file via Fusion.

Step 3. Start vEOS.






Step 4. Make the device accessible from the network.

In order to bypass ZTP, the startup config is not empty. For my image, the username is 'admin' and it will drop you directly into user prompt, there is no enable password. Note that this was not in Andre's instruction as far as I can see.

As indicated by the vmx file, the Management1 interface is in the Fusion bridge network. So I just put an IP that is in the same network as my Ethernet network on the host machine in order to access vEOS.

You can optionally follow these two post if you want to use any of the Ethernet ports off the switch.

https://eos.aristanetworks.com/2012/06/vmware-fusion-virtual-networks/
https://eos.aristanetworks.com/2012/12/building-a-virtual-lab-with-arista-veos-and-virtualbox-2/

Step 5. Follow Mark Berly's instruction on enable eAPI:

https://eos.aristanetworks.com/2013/03/eapi-learning-the-basics/

Here is my snippet for the username/password (http/http) and http server:




Don't forget to create the username and password to access the http interface later on.

Step 6. Access eAPI using your browser. Find a few commands that is supported, not all CLI commands are supported at this time. I have tried 'show version', 'show sflow', and 'show ip interface'.





Step 7. [optional] Install jsonlibrpc if you don't already have it. Since this is the package listed in the example, I just pip installed it.

$ sudo pip install jsonrpclib
Password:
Downloading/unpacking jsonrpclib
  Downloading jsonrpclib-0.1.3.tar.gz
  Running setup.py egg_info for package jsonrpclib
 
Installing collected packages: jsonrpclib
  Running setup.py install for jsonrpclib
 
Successfully installed jsonrpclib
Cleaning up...
$

Step 8. Experiment with the AIP with IPython. In my experience, IPython with autocomplete and question mark query is awesome in trying out new packages.

$ ipython
Enthought Python Distribution -- www.enthought.com

Python 2.7.3 | 32-bit | (default, Aug  8 2013, 05:53:56) 
Type "copyright", "credits" or "license" for more information.

IPython 0.13.1 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: from jsonrpclib import Server

In [2]: switch = Server("http://http:http@[management1 ip]/command-api")


In [3]: response = switch.runCmds(1, ["show version"])

In [4]: response
Out[4]: 
[{u'architecture': u'i386',
  u'bootupTimestamp': 1377616889.2462718,
  u'hardwareRevision': u'',
  u'internalBuildId': u'8051864e-5a59-4349-86c6-1d3725dcd811',
  u'internalVersion': u'4.12.1-1365021.EOS41231',
  u'memFree': 658800,
  u'memTotal': 2033888,
  u'modelName': u'vEOS',
  u'serialNumber': u'',
  u'systemMacAddress': u'00:0c:29:45:1b:64',
  u'version': u'4.12.1-1365021.EOS41231 (engineering build)'}]

In [5]: response = switch.runCmds(1, ["show sflow"])

In [6]: response
Out[6]: 
[{u'datagrams': 0,
  u'enabled': False,
  u'hardwareSampleRate': 1048576,
  u'hardwareSamples': 0,
  u'ipv4Destinations': [],
  u'ipv4Sources': [{u'ipv4Address': u'0.0.0.0', u'vrfName': u'default'}],
  u'ipv6Destinations': [],
  u'ipv6Sources': [{u'ipv6Address': u'::', u'vrfName': u'default'}],
  u'polling': False,
  u'pollingInterval': 2.0,
  u'samplePool': 0,
  u'sampleRate': 1048576,
  u'samplingEnabled': True,
  u'sendingDatagrams': [{u'reason': u'notRunning',
    u'sending': False,
    u'vrfName': u'default'}],
  u'softwareSamples': 0,
  u'totalPackets': 0,
  u'warnings': [u'Displaying counters that may be stale']}]

In [7]: 

To walk thru the keys in the response, we can use two simple nested loop:

In [8]: response = switch.runCmds(1, ["show version"])

In [10]: for i in response:
   ....:     for j in i:
   ....:         print j
   ....:         
memTotal
internalVersion
serialNumber
systemMacAddress
bootupTimestamp
memFree
version
modelName
internalBuildId
hardwareRevision
architecture

Now we can see the keys, then you can simply pick the field you want to see:

In [16]: response[0]['version']
Out[16]: u'4.12.1-1365021.EOS41231 (engineering build)'

In [17]: response[0]['memTotal']
Out[17]: 2033888

In [18]: 


The eAPI is probably one of the most simple and straight forward ways of query network switches out there. Kudos to Arista for coming up with it. WAY easier than screen scraping. Combine with vEOS, it allows the network engineer to easily experiment with the API before deploying in production. 

Leave me comments and let me know what you think of it! 

Eric







Sunday, December 9, 2012

[book review] Arista Warriors



I recently reviewed the book, Arista Warriors. Obviously the Python chapter interested me the most, here is the result of the output as I tried the example in the book to modify the 'show version' output with a few lines of Python. 

***** Experiment on Arista CliPlugin *****


[user@switch CliPlugin]$ pwd
/usr/lib/python2.7/site-packages/CliPlugin
[user@switch CliPlugin]$ sudo vi VersionCli.py

def showVersion( mode, detail=None ):
   <skip>

   # Print commands (delete after)
   print "*" * 10
   print "I dont really like Pie"
   print "*" * 10

[user@switch ~]$ Cli -c "show version"
**********
I dont really like Pie
**********
Arista DCS-7504
Hardware version:    02.00
<skip>
Software image version: 4.10.3
Architecture:           i386
Internal build version: 4.10.3-937242.EOS4103
Internal build ID:      a229c9db-af32-4e62-a4f7-5711e977d968

Uptime:                 6 weeks, 1 day, 22 hours and 51 minutes
Total memory:           4100488 kB
Free memory:            1758148 kB

[user@switch ~]$

That is pretty cool. But how do I write more native looking commands? Or how do I write an agent that can mount to SysDB directly? I dont know, but here are the modules that I plan to look more into for the command part, stay tuned: 

import Tac, CliParser, BasicCli, os, Tracing, EosVersion, Ethernet


***** Review *****



Here is the Review as appeared on Amazon: 

I have been working with Arista switches for a while now, this is the manual that probably should have came with the Arista switches. As the author mentioned, the command syntax the EOS format is very similar to Cisco IOS. In fact, I have heard of stores where engineers simply copy and paste IOS configurations into EOS during migration and worked just fine. However, to tap into the capabilities that makes Arista a game-changer one has to get into the realms of SystemDB, Python, Linux user space, etc. Anybody can type into commands, but the real challenge lies within the impact and scope of what you are trying to do. This book does a good job of doing the practical stuff that you can use in your day-to-day, as well as the concepts behind them.

Overall, I would recommend this as a solid investment of money and time for anybody looking into Arista switches. 

Pro: 

- Real world examples. 
- Solid explanation of concepts. 
- Sense of humor for an otherwise dry subjects. 

Notes, suggestions, erratas: 

1. Maybe more coverage into the current fat tree design with spine/leaf/core, etc. This is one area that Arista differs from competitor for the number of ECMP next-hop, tcam division of host routes, etc. 
2. Power draw is critically important in large scale data centers, Arista has some good innovation in this area with PHY-less design. 

*** Virtual Machines on Arista ***

1. If you don't have an Arista switch handy to practice, or just want a safe environment to practice with, you can run vEOS off a VM: vEOS, https://eos.aristanetworks.com/2011/11/running-eos-in-a-vm/ by Andre Pech. 
2. When you are in a pinch, you can also run another VM direction in EOS: Running Virtual Machines in EOS, https://eos.aristanetworks.com/2011/09/virtual-machines-in-eos/ by Mark Berly. 

*** sFlow ***

The whole chapter on sFlow probably warrants more coverage. This is one important telemetry tool that offers lots of information and the right direction going forward, IMO. It offers the ability to do push telemetry vs. pull such as SNMP that offers more scalability. 

It is also important in the sense of data center billing for the counter. If you are, say, Yahoo and have one of the biggest Hadoop cluster. You would want to know who is your top talker so you can bill them the network overhead accordingly. This is typically done with NetFlow that exports to collector (more on it in a bit), but if you have a network of Arista switches that does not cross the core, sFlow counter is your current best bet. 

Because aggregation is done in the onboard flow cache 'before' it sends to collector, NetFlow often falls down in even moderate amount of traffic in data centers. You are forced to scale down on the flow sampling rate that increases the error delta. sFlow on the other hand, just samples and push all the intelligence into the collector. 

The author hints at this, but here is an early peak on troubleshooting data plan traffic with sflowtools: 

1. Running the open source sflowtools directly on Arista switches for troubleshooting data plan traffic that does not cross CPU. https://eos.aristanetworks.com/wiki/index.php/EOSTroubleshooting:Local_sFlow_Collection_and_Analysis
arista#bash sudo /mnt/flash/sflowtool -t | tcpdump -r - -vv

*** Python ***

Python should have more coverage in the book as that is what Arista CLI is built on. Just some pointers toward motivated Network Engineers which modules to look more into and the location of the files would be helpful. 

1. I have asked when Python 3 will be included in Arista, best guess is when Fedora updates their OS to make 3 default. 

*** Random Notes about the book ***

1. I think 'sh run all interface' was in 4.7.x, then for some reason went away in 4.8.x, then came back after 4.9.x.  
2. I wish the book covers more on the SysDB mount points that Mark Barley points out on EOS Central. 
3. IPv6 chapter in the works with 4.10.x code? 
4. Nice tip about generating traffic at 'ping -s 15000 -c 10000 10.10.10.15 > /dev/null &' I have done that before but couldn't see the traffic right away and killed it. 
5. Why woundn't cron work on Arista (chapter 23)? 
6. Nice tips: didn't know that tcpdump can be executed directly from EOS, files other than selected few locations do not survive reloads, emails, etc. 
7. ZTP chapter: chapter typo, should be EOS 4.7 and after, not 3.7. 
8. ZTP chapter: instead of identifying by mac address, should identify via relay agent or the place of kingdom (show lldl) via script instead of by mac address. The mac address change due to RMA, typo. Also manually mocking DHCP config file does not scale. 
9. Event-Handler chapter: More event-handler trigger is indeed needed in Arista in order for the feature to be more useful.
10. Event-Handler chapter: tJust like regular bash script, you can 'demonize' and chain the commands with ';'.
22. Event-handler chapter: There is at least one bug in event-handler in 4.8.3 that configuring 'on boot-up' triggers the event-handler right away. Be careful if the startup script include anything that is production impacting. 
23. I like the 'advance usage of sqlite' a lot, gives me some ideas for using sqlite for other features as well. Maybe show the Python integration with sqlite for script purposes?
27. I like what the author pointed out the different between the default flash: location vs. having to specify full Unix path via file: command. I wish I had known this, would've saved me a some time copying stuff from /var/log -> /mnt/flash -> transfer. 
28. CloudVision: I wouldn't recommend the use of XMPP in production either. Use the upcoming JSon API instead. 
29. Page 360, pretty sure that 'spline' is a typo for 'spine'. 
30. Here is a talk by Andy Bechtolsheim in NANOG 55, helps to understand Arista's vision: http://www.nanog.org/meetings/nanog55/abstracts.php?pt=MTk0MSZuYW5vZzU1&nm=nanog55

*** Commands that I wish the book included ***

1. favorite command: 'show interface counters rates | nz'
2. switch(s1)#sh logging last ?
  <1-9999>  Number of time units (sec|min|hr|day)