It took years after NETCONF RFCs were published before IETF standardized YANG. It took another half-decade before they could agree on how to enable or disable an interface, set interface description, or read interface counters. A few more years passed by, and finally some vendors implemented some of the IETF or OpenConfig YANG data models (with one notable exception).

Now that we have the standardized structure, it’s easy to build automated multi-vendor networks, right? Not so fast…

Found this great quote in Algorithms to Live By: The Computer Science of Human Decisions - a must-read for all nerds:

Depend upon it there comes a time when for every addition of knowledge you forget something that you knew before. It is of the highest importance, therefore, not to have useless facts elbowing out the useful ones.

Sherlock Holmes

Now you know why you should focus on how things work instead of memorizing commands ;)

After describing the basics of internal data center switch architectures, JR Rivers focused on the crux of the problem the vendors copiously exploit to create a confusopoly: is it better to use big- or small-buffer switches?

EVPN is one of the major reasons we’re seeing BGP used in small and mid-sized data center fabrics. In theory, EVPN is just a BGP address family and shouldn’t impact your BGP design. However, suboptimal implementations might invalidate that assumption.

I've described a few EVPN-related BGP gotchas in BGP in EVPN-Based Data Center Fabrics, a section of Using BGP in Data Center Leaf-and-Spine Fabrics article.

J Metz published a great article describing six hard truths not taught in school. As all good things should come in 7-tuples, here’s another one I was told ages ago when I was a young hotshot full of myself:

Professions were created for a reason – they enable people to do the work they’re qualified to do.

Needless to say, it took me decades to fully understand its implications.

Last week I described what we did in 2017. Now let’s see what the ipSpace.net subscribers will get in 2018.

New webinars

I thought that 2017 would be a year of the cloud, but that was not to be – I was too busy creating network automation and data center content.

While I have stock homework assignments prepared for every module of the Building Network Automation Solutions online course I always encourage the students to pick a challenge from their production network and solve it during the course.

Pavel Rovnov decided to focus on consistency of network management parameters (NTP, SNMP, SSH and syslog configuration) across Extreme and Cumulus switches, Fortinet firewalls and several distributions of Linux.

Linux operating system is used as the foundation for numerous network operating systems including Arista EOS and Cumulus Linux. It provides most networking constructs we grew familiar with including interfaces, VLANs, routing tables, VRFs and contexts, but they behave slightly differently from what we’re used to.

In Software Gone Wild Episode 86 Roopa Prabhu and David Ahern explained the fundamentals of packet forwarding on Linux, and the differences between Linux and more traditional network operating systems.

2017 was one of the busiest years since I started the ipSpace.net project.

It started with an Ansible for Networking Engineers session covering advanced Ansible topics and network device configurations. Further sessions of that same webinar throughout 2017 added roles, includes, extending Ansible with dynamic inventory, custom modules and filters, and using NAPALM with Ansible.

One of the first things I did when I started my deep-dive into network automation topics was to figure what tools people use to automate stuff and (on a pretty high level) what each one of these tools do.

You often hear about Ansible, Chef and Puppet when talking about network automation tools, with Salt becoming more popular, and CFEngine being occasionally mentioned. However, most network automation engineers prefer Ansible. Here are a few reasons.