from Hacker News

Automate Your Network

by hjuutilainen on 7/3/23, 3:01 PM with 34 comments

  • by runjake on 7/3/23, 3:25 PM

    The author states they have evolved from Ansible to pyATS[1], but pyATS is a Cisco project. With Cisco's poor code project and open source track record, I'm not sure how this is much of an improvement, and IMHO, it's arguably worse.

    For possible alternatives, check out NAPALM[2] and Nornir[3].

    It's also worth checking out Python for Network Engineers[4].

    1. https://developer.cisco.com/docs/pyats/

    2. https://napalm.readthedocs.io/en/latest/

    3. https://nornir.readthedocs.io/en/latest/

    4. https://pyneng.readthedocs.io/en/latest/index.html

  • by nu11ptr on 7/3/23, 4:19 PM

    I do network automation for a profession. I build tools (technically compilers) that take a proprietary object model designed for our private cloud and translate that into Ansible (v1) or Terraform (v2) code. At our company, I actually call using these tools in isolation doing it "manually". This is because the largest benefit of automation, I believe, is the abstraction gained from the new object model and being to to generate and store the inputs for Ansible/Terraform in a database. If you have to track and specify all the inputs into Ansible/Terraform and write the playbooks/HCL manually it is my experience you don't actually save all that much work. However, when you have an object model specifically designed for your use case, you can deliver a new client network in literally minutes (essentially nothing more than the cloud model, exactly what AWS/Azure, etc does for their networking). The downside is most enterprises don't have people like me to write the code to do this, and writing it for a single deployment would likely not see the gains that we see as a managed service provider.

  • by theideaofcoffee on 7/3/23, 3:33 PM

    I glanced through the guide and it's Windows and Cisco (specifically IOS) heavy: mentions of the old Cisco architecture via Core/Access/Distribution, where larger DC networks have converged onto spine/spline setups, CDP/Cisco Discovery protocol whereas the open-source LLDP is more generic, even the nomenclature of 802.1q VLAN tags: access versus trunk. But I guess if you are starting to automate a legacy office network, it might be useful.

    More recent non-IOS network OSes that lend themselves to automation, especially in the datacenter, the likes of Cumulus or SONiC are pure linux with some asic-vendor-specific bits and bobs, so I'm unsure of the applicability of this guide to larger, more modern networks. Tools like ansible could be a good fit here, but since they are 'just' linux, might as well use a dedicated config management tool like chef or puppet.

    Otherwise I think it's well written for someone in a smaller shop wanting to get their feet wet with ansible and other tools but still stuck on IOS.

  • by dvno42 on 7/3/23, 6:59 PM

    Hey this is cool! Thanks for sharing your hard work.

    I have been living this for the past few years building an automation product[0] and services company to lower the barrier of entry and have tested many of these methodologies. We’ve also written many different runbooks/playbooks for complicated workflows. I’d like to share a couple experiences/opinions:

    Netconf and vendor apis are lovely when available and working well. Many devices don’t support this and falling back to SSH (sometimes even telnet) is a must for automation. Imo, you could add value to your book by touching on Ktbyer's Netmiko/Paramiko[1] as well as their nuances (timeouts, dealing with interactive prompts, etc).

    AAA is a big component of automation too. Having something in place to handle authn/authz (radius/tacacs) enables consistency for access across vendors. This also enables least privileged accounts and rotation/limited lifetime of creds when used with something like Hashicorp Vault[2]. I think you briefly mentioned secrets management though Ansible vault.

    Another technology that may be worth mentioning is Textfsm[3] in conjunction with Netmiko. When we automate workflows for clients, there’s often times where the data we need to parse isn’t easily parsable. Using and expanding on textfsm makes this doable.

    Lastly, much automation may only be one firmware change away from breaking. Even with the big vendors, bugs are common that are (ime) low priority to the OEM. Keep this in mind when writing runbooks/playbooks, try to rely on features and output that are unlikely to change across versions.

    [0]https://realmhelm.com [1]https://github.com/ktbyers/netmiko [2]https://github.com/hashicorp/vault [3]https://github.com/google/textfsm

  • by metadat on 7/3/23, 6:44 PM

  • by betaby on 7/3/23, 8:49 PM

    ctr+f 'yang' - nothing

    ctr+f 'netconf' - nothing

  • by SergeAx on 7/4/23, 9:18 PM

    > I believe in open source software

    But... PDF is not "open source", it is literally a compiled binary blob :)

    This is pretty cool book though. If author reading this: can you please publish real source files for the book?