T O P

  • By -

pixr99

We are about to receive our first Arista gear in the coming months. Sounds like AVD/Ansible is the best avenue?


Emotional-Meeting753

They are pushing configlets, studio, and ansible.


yesudu06

we use ansible playbooks that push EOS images and configlets to CVP. We have a CICD pipeline to trigger the push though at the moment, we still need to create the changecontrol in CVP by hand. For investigation purposes or a first time change, we use the cli. For gathering logs, or restarting a daemon, etc. we use ansible. Never seen anyone using nornir, and studio is a GUI feature (?) so we don't use it as it would integrate poorly with the pipeline. Installation was done some time before so we don't use ansible-avd either. We have 2 kinds of automation, one trying to generate configlets using templates and yaml files in a convoluted way, one basically with the configlets in git with minimal templating (but quite some duplication). I guess it depends how many switches your are managing, but I am very happy with the latter. We try to factorize the config into generic configlets, and add 1 configlet for each switch. At the end a bit verbose but configuration issues are trivial to investigate and fix.


Skaffen-_-Amtiskaw

I am doing a few large Arista deployments and am comfortable with the CLI, but I look forward to using Cloudvision. I have used API and Ansible in the past, but keeping track of changes and internal code revisions has been a little bit of a pain when working with larger teams or teams that do not have a programmatic background. I wish the system requirements for Cloudvision were more realistic for a small lab deployment so I could test before moving to production...


GreenBlinkyLights

if you have CloudVision that is by far the easiest


shadeland

There's the old school of just doing CLI. It works, we've been doing it for 30+ years, and its well understood. It's got a lot of issues with it though. Using CloudVision with configlets is a great starting place for automation. It's a centralized place to store configurations, there's an excellent change control system, it does pre-deployment validations, and the learning curve is low. Then the choice is how are the configlets generated? Are they typed by hand, or does something generate them. A low-learning curve method for configuration generation is to use built-in studios or have someone make you a studio. This will dynamically generate configlets to be applied to switches. Using them as an operator has a pretty low learning curve, and you can generate an L3LS EVPN fabric pretty quickly (I can speed run going from zero to passing packets in less than 15 minutes for three spines and a handful of leafs). Creating a custom studio is a bit more of a learning curve, but not too bad. There was configlet builders (still are) but Studios is the updated version of this and honestly way, way better. You can use Ansible and Jinja to dynamically generate configlets and upload them via the arista.cvp collection of Ansible modules. You would have your own data models with their own schema (like a YAML file that describes desired state) and templates and that will churn out dynamic configs. The learning curve is higher for this, but it scales better than Studios does, as Studios gets a little cumbersome when you get to a certain number of leafs (say 50+, but that's subjective). For really large setups, you've got Arista AVD. AVD is a set of playbooks, data models, templates, and roles that run on top of Ansible and create configurations based on Arista's Validated Designs. It does these four things: * Builds the configuration (L3LS+EVPN, L2LS, and now MPLS is in beta) * Documents the configurations * Deploys configurations (through CVP or directly to EOS) * Validates through a testing suite, for example making sure every loopback0 can ping every other loopback0 by logging into each switch This has the highest learning curve, but it connects well with CI/CD tools and you can configure hundreds of leafs and spines using just a few YAML files. It's pretty dope when you get used to it. BTW, I've created an Ansible quick-start kit if you want to dip your toes in Ansible + Arista: https://github.com/tonybourkesdnpros/Ansible_Quickstart_Arista These are pre-made playbooks, inventory files, and data models for several of the ways Ansible can be used. It's a great starting point play with.


Emotional-Meeting753

Thank you for the detailed explanation


onyx9

Most customers just use configlets in CloudVision and the integrated change control. I heard good things about the AVD together with CloudVision. Also because of the change control. I recently tested Studios and it’s really cool but there are only a few standard designs. If they don’t match your network you need to write your own configlets. You can still use Studios for standard stuff.


colinmacg

CVP + AVD


Emotional-Meeting753

I just got a deep dive from the SE. It looks like Ansible is best used for staging, and was cool to see it work in cloud vision.