Upcoming Webinars and Events: October 2018

The fast pace of webinars continues in October 2018:

• Rachel Traylor will talk about graph theory and its relevance to reliable network design on October 8^th;
• The Amazon Web Services Networking webinar will start on October 11^th. The second session is planned for October 25^th;
• On October 16^th we’ll have the third session of VMware NSX technical deep dive (unless I manage to finish on time later today… not likely).

There are no on-site events planned until early December:

• We’ll run another on-site workshop in Zurich on December 5^th . This time we’ll focus on using VXLAN and EVPN to build multi-site fabrics;
• I’ll talk about making SDN better with IPv6 on December 6^th.

You can attend all upcoming webinars with an ipSpace.net webinar subscription. Online courses and on-site events require separate registration.

VXLAN Broadcast Domain Size Limitations

One of the attendees of my Building Next-Generation Data Center online course tried to figure out whether you can build larger broadcast domains with VXLAN than you could with VLANs. Here’s what he sent me:

I'm trying to understand differences or similarities between VLAN and VXLAN technologies in a view of (*cast) domain limitation.

There’s no difference between the two on the client-facing side. VXLAN is just an encapsulation technology and doesn’t change how bridging works at all (read also part 2 of that story).

Smart or Dumb NICs on Software Gone Wild

Hardware vendors are always making their silicon more complex and feature-rich. Is that a great idea or a disaster waiting to happen? We asked Luke Gorrie, the lead developer of Snabb Switch (an open-source user-land virtual switch written in Lua) about his opinions on the topic.

TL&DL version: Give me a dumb NIC, software can do everything else.

If you want to know more, listen to Episode 93 of Software Gone Wild.

Using CSR1000V in AWS Instead of Automation or Orchestration System

As anyone starting their journey into AWS quickly discovers, cloud is different (or as I wrote in the description of my AWS workshop you feel like Alice in Wonderland). One of the gotchas: when you link multiple routing domains (Virtual Private Clouds – the other VPC) you have to create static routing table entries on both ends. Even worse, there’s no transit VPC – you have to build a full mesh of relationships.

The correct solution to this challenge is automation:

Infrastructure-as-Code, NETCONF and REST API

This is the third blog post in “thinking out loud while preparing Network Infrastructure as Code presentation for the network automation course” series. You might want to start with Network-Infrastructure-as-Code Is Nothing New and Adjusting System State blog posts.

As I described in the previous blog post, the hardest problem any infrastructure-as-code (IaC) tool must solve is “how to adjust current system state to desired state described in state definition file(s)”… preferably without restarting or rebuilding the system.

There are two approaches to adjusting system state:

Data Point: Why Automation Won’t Replace Humans

Here’s a bit of good news for those of you scared of network automation replacing your jobs: even Elon Musk didn’t manage to pull it off, so I don’t think a networking vendor dabbling in intent will manage to do it (particularly considering the track record of networking vendors’ network management and orchestration systems).

Valley-Free Routing in Data Center Fabrics

You might have noticed that almost every BGP as Data Center IGP design uses the same AS number on all spine switches (there are exceptions coming from people who use BGP as RIP with AS-path length serving as hop count… but let’s not go there).

There are two reasons for that design choice:

Video: What Is SDWAN?

Pradosh Mohapatra, the author of last week’s SD-WAN Overview webinar started his presentation with a seemingly simple question: What Is SD-WAN?

You need at least free ipSpace.net subscription to watch his answer.

Worth Reading: Intent-Based Networking Taxonomy

This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.

Saša Ratković (Apstra) published a must-read Intent-Based Networking Taxonomy which (not surprisingly) isn’t too far from what I had to say about the topic in a blog post and related webinar.

It’s also interesting to note that the first three levels of intent-based networking he described match closely what we’re discussing in Building Network Automation Solutions online course and what David Barroso described in Network Automation Use Cases webinar:

Adjusting System State with Infrastructure as Code

This is the second blog post in “thinking out loud while preparing Network Infrastructure as Code presentation for the network automation course” series. If you stumbled upon it, you might want to start here.

An anonymous commenter to my previous blog post on the topic hit the crux of the infrastructure-as-code challenge when he wrote: “It's hard to do a declarative approach with Ansible and the nice network vendor APIs.” Let’s see what he was trying to tell us.

Network Automation with Ansible for Undergraduate Students

Last year’s experiment generated so much interest that I decided to repeat it this year: if you’re an undergraduate or Master's student and manage to persuade us that you’re motivated enough to automate the **** out of everything, you’ll get a free seat in Ansible for Networking Engineers online course.

Interested? Check out the details, and apply before October 1^st.

Too old? Please spread the word ;)

Routing in Data Center: What Problem Are You Trying to Solve?

Here’s a question I got from an attendee of my Building Next-Generation Data Center online course:

As far as I understood […] it is obsolete nowadays to build a new DC fabric with routing on the host using BGP, the proper way to go is to use IGP + SDN overlay. Is my understanding correct?

Ignoring for the moment the fact that nothing is ever obsolete in IT, the right answer is it depends… this time on answer(s) to two seemingly simple questions “what services are we offering?” and “what connectivity problem are we trying to solve?”.

Repost: Tony Przygienda on Valley-Free (or Non-ZigZag) Routing

Most blog posts generate the usual noise from the anonymous peanut gallery (if only they'd have at least a sliver of Statler and Waldorf in them), but every now and then there's a comment that's pure gold. The one made by Tony Przygienda (of RIFT fame) on Valley-Free Routing post is so good and relevant that I decided to republish it as a separate blog post. Enjoy!

Worth Reading: IPv6 Renumbering == Pain in the …

Johannes Weber was forced to stress-test the IPv6 networks are easy to renumber nonsense and documented his test results – a must-read for everyone deploying IPv6.

He found out that renumbering IPv6 in his lab required almost four times as many changes as renumbering (outside) IPv4 in the same lab.

My cynical take on that experience: “Now that you’ve documented everything that needs to be changed, make sure it’s automated the next time ;)”

Valley-Free Routing

Reading academic articles about Internet-wide routing challenges you might stumble upon valley-free routing – a pretty important concept with applications in WAN and data center routing design.

If you’re interested in the academic discussions, you’ll find a pretty exhaustive list of papers on this topic in the Informative References section of RFC 7908; here’s the over-simplified version.

Network Infrastructure as Code Is Nothing New

Following “if you can’t explain it, you don’t understand it” mantra I decided to use blog posts to organize my ideas while preparing my Networking Infrastructure as Code presentation for the Autumn 2018 Building Network Automation Solutions online course. Constructive feedback is highly appreciated.

Let’s start with a simple terminology question: what exactly is Infrastructure as Code that everyone is raving about? Here’s what Wikipedia has to say on the topic:

Do We Need Leaf-and-Spine Fabrics?

Evil CCIE left a lengthy comment on one of my blog posts including this interesting observation:

It's always interesting to hear all kind of reasons from people to deploy CLOS fabrics in DC in Enterprise segment typically that I deal with while they mostly don't have clue about why they should be doing it in first place. […] Usually a good justification is DC to support high amount of East-West Traffic....but really? […] Ask them if they even have any benchmarks or tools to measure that in first place :)

What he wrote proves that most networking practitioners never move beyond regurgitating vendor marketing (because that’s so much easier than making the first step toward becoming an engineer by figuring out how technology really works).

Is BGP Good Enough with Dinesh Dutt on Software Gone Wild

In recent Software Gone Wild episodes we explored emerging routing protocols trying to address the specific needs of highly-meshed data center fabrics – RIFT and OpenFabric. In Episode 92 with Dinesh Dutt we decided to revisit the basics trying to answer a seemingly simple question: do we really need new routing protocols?

Traditional Leaf-and-Spine Fabric Versus Cisco ACI

One of my subscribers wondered whether it would make sense to build a traditional leaf-and-spine fabric or go for Cisco ACI. He started his email with:

One option is a "standalone" Spine/Leaf VXLAN-with EVPN deployment based on Nexus equipment. This approach could probably be accompanied by some kind of automation like Ansible to ease operation/maintenance of the network.

This is what I would do these days if the customer feels comfortable investing at least the minimum amount of work into an automation solution. Having simpler technology + well-understood automation solution is (in my biased opinion) better than having a complex black box.

Interview: Benefits of Network Automation (Part 2)

As promised, here’s the second part of my Benefits of Network Automation interview with Christoph Jaggi published in German on Inside-IT last Friday (part 1 is here).

What are some of the challenges?

The biggest challenge everyone faces when starting the network automation is the snowflake nature of most enterprise networks and the million one-off exceptions we had to make in the past to cope with badly-designed applications or unrealistic user requirements. Remember: you cannot automate what you cannot describe in enough details.