Request: intro materials

[jzohrab]

I'm looking to try out Napalm, but I have ​no idea​ where to start. I've read the docs on github. I have a coding background and CCNA-level networking understanding, which should be sufficient to try out the basics. Familiar with Python, have used Chef and am happy to try out Ansible. I'm okay to try out Ansible. My ideal tutorial would include the following:

• setting up a vagrant box or similar for local testing
• setting up Ansible (seems like path of least resistance)
• creating a simple config
• using Ansible to push it out to the device

I'd be interested in creating an intro tutorial like the above, if I can get some guidance. I have some networking colleagues who would likely benefit from such material as well.

[ande0581]

@jzohrab You could check out some of kirks byers articles.

https://pynet.twb-tech.com/

He also has a formal course that covers a lot of what you are asking about.

https://pynet.twb-tech.com/class.html

[ktbyers]

@jzohrab I wrote this article here regarding NAPALM and Cisco ios (which might help):

https://pynet.twb-tech.com/blog/automation/napalm-ios.html

[jzohrab]

Thanks @ande0581 and @ktbyers for your input, appreciated. @ktbyers I'd read that already, thanks for posting it.

I think what I'd like to see - for myself, and perhaps as a quickstart for the project - would be a simple set of instructions to set up a lab environment locally, including Ansible etc, so that I have something running that I can immediately hack around with. It's not a place for me to learn about Ansible or other things, but rather just for me to get up and running. I often find that setting up tools etc is an exercise in frustration, and having a low-friction entry is valuable.

There's already a Vagrantfile in the code here. I submitted a PR for review and discussion that I hope would also simplify devs getting involved with the project.

I think all the pieces are in place, and it's just a matter of putting together a simple tutorial for people like me to follow to get something up and running very quickly, so I can get an end-to-end understanding of what Ansible can do on my own box. The vagrantfile stuff might be tough with some vendors due to licensing, but maybe one of the other vendors has a free/student/whatever version that would be enough.

[dbarrosop]

Hello @jzohrab, there are a lot of resources out there to set up a lab. For example, I wrote:

https://www.dravetech.com/blog/2016/01/08/vagrant-for-network-engineers.html https://www.dravetech.com/blog/2016/01/14/vagrant_box_ios_xr.html

to get started with vagrant. There are also the videos and article linked on the README and a couple of tutorials in the documentation:

http://napalm.readthedocs.org/en/latest/tutorials/index.html

They should cover more or less everything but unfortunately the guides are a bit disperse to say the least.

If you are willing to piece everything together and create a tutorial where everything ties together I think it would be great. Ofc, don't hesitate to ping me here or on slack or by mail if you have questions. The slack channel is great as a lot of people there knows what they are doing and you might get instant help ;)

Regarding the vagrant box, as you mentioned, the problem is the licensing. JunOS has a vsrx you can get directly from hashicorps' repository. Main problem is that it's a VERY old platform and sometimes extremely slow and flaky. Best option IMHO is the vEOS box. You have to register to download it but other than that it's free to download and works great.

[jzohrab]

Thanks @dbarrosop, very happy to contribute. I'll create a separate GitHub project to put this material together, with the goal of somehow merging it into the main Napalm project, or as a separate GitHub repo (to generate docs from). I can get a Cisco OVA via work, but will keep the VEOs suggestion in mind.

[dbarrosop]

I suggest you to clone the napalm and work on the docs folder. That way when you subimit the PR and it's accepted it will publish by the grace of CI directly into RTD : )

If you are unfamiliar with sphinx let me know and I will give you some pointers to get started.

I can get a Cisco OVA via work, but will keep the VEOs suggestion in mind.

The main reason why I suggested vEOS is because anyone can get it easily. I guess that the cisco OVA requires some entitlement. So if you want to write a guide that anyone can follow vEOS is probably your best bet.

[jzohrab]

Will start working on docs at https://github.com/jzohrab/napalm/tree/wip_intro_docs. I may not get very far with it.

Ack on vEOS. Apparently Cisco does offer a virtual Nexus N9000/N3000 for development and testing, ref https://github.com/cisco/cisco-network-chef-cookbook/blob/develop/docs/README-agent-install.md. I won't follow up on that at this moment, though.

If people would like to push up there, I can add them as collaborators. You can send me messages via slack about what to include also, I'm on networktocode slack. I have some refs above I'll look into.

[mirceaulinic]

@jzohrab Do you have available a real network, or only VMs? Is Ansible a must for you?

[jzohrab]

Hey @mirceaulinic - I do have a real network. This issue, and the branch I'm working on, is for newcomers who want to try out Napalm quickly. There are docs out there, but I wasn't sure what to do when I first started (and still don't, when it comes to the Ansible side). When I'm starting out with new tech, I like to be up and running with it as soon as possible, and not have to google for anything. At least, not within reason.

Ansible is not a must, but it seems that this is what the networking community likes. I think I'd prefer Chef, but don't have enough knowledge to make a good call.

[mirceaulinic]

Anyway it does not make any difference at the end of the day.

If you don't have any constraints regarding the tools you need to use, would you mind trying Salt? You'd be the very first person outside CloudFlare trying it (I think).

A couple of months ago, we, at CloudFlare, have evaluated the available tools in order to automatise our network. Indeed Ansible is the most used, but didn't cover our expectations. Thus we have picked up Salt from a couple of reasons:

• engineers from other teams already familiar with this environment
• Salt already manages thousands of our servers around the world, thus extremely scalable
• with Ansible we were able only to retrieve and push configs. What happens between those two events, was a huge question mark
• Salt, on the other hand already had all the advantages you would need (covering more than you'd need on the server side):
  • retrieve data/config (module)
  • caching (mine)
  • group devices by properties (e.g. on network side: you can select by vendor, select by firmware, by firmware version, by country, or devices whose hostnames respect a regex, etc, -- actually imagination is the only limit) -- this is called grains
  • config check & enforcement (state)
  • push config (module)
  • save the retrieved data in a specific format, in a specific place (returners)
  • not just retrieve data, but there are also so called "runners" that allow you to go through all of your network devices (or selected group of devices using the grains) and adapt the output to your needs (e.g. we already have in production tools able to find an IP/MAC address and within 2s looks in all our devices, in all MAC Address Tables, ARP Tables and Interfaces IPs)

It already has all the tools you can need: connection to SQL/NoSQL databases (Postgres, MySQL, Cassandra, Redis etc), file management, git, hadoop etc. The list is too long and does not make sense to write down here. I bet you won't have time as much as you can do!

Salt was mainly designed for the server side, but recently they have introduces the Proxy minions. You can use the proxies, having a good library like NAPALM, to connect to the network device and instruct Salt to do all the things you would need.

Over the last months we begun integrating NAPALM in Salt:

• The proxy: https://github.com/saltstack/salt/blob/develop/salt/proxy/napalm.py
• Two modules:
  • NET: https://github.com/saltstack/salt/blob/develop/salt/modules/napalm_network.py
  • NTP: https://github.com/saltstack/salt/blob/develop/salt/modules/napalm_ntp.py
• NTP state: https://github.com/saltstack/salt/blob/develop/salt/states/netntp.py

They will be fully integrated in the next couple of months and there will be much more modules available soon enough.

You can try it out following the instructions I wrote here: https://github.com/napalm-automation/napalm-salt

When will be fully integrated in Salt, you'll only need to type two simple command lines and boom: you can manage your network:

# apt-get install salt-master
# pip install napalm

How does this sound to you?

[jzohrab]

Hey @mirceaulinic - this sounds interesting. I don't know how much should be incorporated into an early introduction of Napalm, which is what I'd like to limit the scope to here. This was for people to get up-to-speed with Napalm only, and as Ansible appears to be the easiest to get started with, I thought it would be a good choice.

The intent is to submit this back to the Napalm master branch, so once it's there anyone can contribute to these "getting started" tutorials. Maybe a link to Salt's doc should go on there.

When I return to this, I'll finish with Ansible (reflecting the current community trend), and then we can figure out how to add other items.

Thanks for posting, it does sound interesting! Regards, jz

[mirceaulinic]

Yes, absolutely, go ahead with the introduction for NAPALM, I like the idea.

Being open to something new, I just took the chance to propose you what we consider a more complete technology.

The community is using Ansible because back in time (about 2 years ago perhaps) it was the best solution. Salt existed, but available only for servers, not for other type of devices. But not anymore and brings the all advantages for all types of devices now.

Easier is not always the answer in networking (e.g.: for us it would be way easier (and cheaper) to setup a vMX instead of buying MX480s). But performance is what it does matter. Moreover, I assume you are not working right on Windows 7 (as 45% of the world) just because most of the people use it. You use what fits you the best.

And anyway, I don't see what can be easier than executing 2 lines (3 till NAPALM will become part of Saltstack) to setup the whole environment you need. The rest are just config files, specific to your network only.

And don't take me wrong: we don't support a technology just because its name begins with "S" instead of "A". We don't support "a" technology, we want a better Internet and we mean it. Salt, we simply find it as the best you can get right now, why would we miss this chance, especially when it covers absolutely all your needs? Isn't fun that technology changes so fast?

However, here it might not be the right place for such topic. For further discussions / ideas / reports, feel free to open an issue in napalm-salt. Cheers.

[jzohrab]

Right, I'm not sold on Ansible myself. Our shop uses Chef, and Ansible feels too easy - it's basically ssh with some wrapping, it seems. I wouldn't want this quickstart to be seen as Ansible endorsement. So after the quickstart w/ Napalm and a Vagrant VM, it could branch off to different tracks for config management, or just refer to existing documentation. The discussion for which config management solution is best is outside of the scope of this quickstart, and so we should be sure to include enough info for people to get started with each of them, or to understand what is required.

[dbarrosop]

My two cents, ansible is a slow but very powerful 'scripting' framework that allows you to organize your systems and reuse common code in the form of modules or libraries. The scripting framework is versatile enough that allows you to build a configuration management system. What's appealing of ansible is precisely that; it's super easy (mostly YAML or some python if you want to write your own modules) and super versatile. So I am not sure if chef/puppet/salt are really comparable with ansible.

In any case, let's try not to turn this thread into a flame war. We can continue this conversation on a new thread, on the mailing list or even on slack : )

[mirceaulinic]

(mostly YAML or some python if you want to write your own modules) and super versatile. And here comes the question: what if you are a network engineer and never ever in your life have typed one single line in Python, but have a need? Do we want to force all net engineers learn Python, or just provide them a tool they can simply use? So I am not sure if chef/puppet/salt are really comparable with ansible. Actually they are (unless you have a strong desire to reinvent the wheel over and over again, when other people already invented it for you) :) Please check it out, many things changed in the last couple of months ;)

[jzohrab]

For the scope of this tutorial/intro materials, let's stick with Napalm itself. I have the quickstart running for Napalm itself and a VM - really just recompiling existing material. We can add the config mgmt options later.

[jzohrab]

PR #235 replaced by #238, a PR into a separate feature branch.

[dbarrosop]

I have finally merged this into master. It took forever and I apologize for that.

Thanks, it's really awesome : )

[jzohrab]

Cheers, thanks @dbarrosop, hope it's useful for newbies!