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/
When you are ready to deploy I "compile" the object model data into an IR (representing the "network topology") and then make a final pass and translate into HCL for all the various backends.
I'm not saying its "better" as it has trade offs. I'm saying for networks specifically, it is the only way I've seen in the real world to give these tools lots of value. Otherwise the network engineers end up spending all their time looking up the input data (vlans, subnets, ips, etc.) which is the part that is most time consuming for manual configuration as well. The validation and auto-generation of the input data is where the value comes in.
In the book, the author presents an approach for storing the object state and organizing the repository for ansible purposes in what is at least as sensible a way as any other I've seen. For installations that might not directly benefit from additional layers of abstraction, managing object model state using ansible's native functionality might well be sufficient.
This is all a legitimate challenge, in any case. Network infrastructure and service instances have some management issues in common, but where they differ, they can differ by quite a bit, in ways that are hard to model at any level of abstraction.
I wasn't critiquing the author, but networks inherently have a lot of input data. Much of this is not of concern to the end user, hence why public clouds require almost zero input on the network side.
I agree that my object model is purpose built for our product. It would not work for someone else's network.
Thank you
Iow, it is custom set of lego bricks that can only be combined in certain ways to build valid networks. It is propriety to our cloud product which has the benefit of allowing us to abstract things away that others probably couldn't, but the downside of making it entirely non-reusuable for a different use case.
looking today at all the manual work with playbooks/etc, it's astonishing. feels like things didn't move forward at all in past decade
For instance in AWS you still have to care about BGP and ASNs if you want to follow the most seamless approach to create a multi-region mesh of VPCs. Why should I have to care about that? AWS already knows where all the packets came from and where they're going and should just put them in the right place. I don't care how they get there and I certainly shouldn't have to care about BGP attributes[1].
1. https://docs.aws.amazon.com/network-manager/latest/cloudwan/...
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.
Please correct me if I'm wrong, but I see the "old" core/access/distribution layers still relevant. The datacenter spine/spline setup applies to networking between server racks in the data center.
> 802.1q VLAN tags: access versus trunk
Again, are you saying that these are outdated? I'm not a practicing network engineer, but I know several network engineers and they've told me that understanding 802.1q VLAN tags to segment network traffic has been helpful.
this is correct. The place where spine-leaf really shines is when used in combination with evpn-vxlan. You can then encapsulate every tenant network inside a VXLAN domain and route those between your leafs switches through your spine layer.
This is basically a clos fabric which is non-blocking, and is very easy to expand horizontally. It also gives you nice features like ARP suppression[0]. These features are important in a DC fabric because ARP flooding is traffic which is not revenue generating, and should be minimized as much as possible.
For normal Enterprise/Office network, running an evpn-vxlan fabric is usually far to complex for the benefits involved.
[0] https://satishdotpatel.github.io/how-does-arp-suppression-wo...
I think the parent was saying that these are Cisco specific terms; more generic terms would be "untagged" + "tagged".
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
This ties in to your point about how you often need to fallback to SSH or Telnet. For example, a lot of platform-specific data isn’t exposed through standard interfaces, but almost everything is available through a CLI. There are also times when you have no choice but to use the CLI - for example, when re-imaging or reloading a device.
https://github.com/automateyournetwork/automate_your_network...
ctr+f 'netconf' - nothing
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?
