Blog Posts in October 2017
I love reading well-argued contrarian views, and Geoff Huston’s Opinion in Defense of NAT is definitely worth the time it will take you to read it.
TL&DR: Geoff argues that with all the wastage going on in IPv6 land (most bizarre: let’s give a /48 to every residential subscriber) the number of bits available for IPv6 endpoint addressing gets close to what we can squeeze out of IPv4 NAT.
Do I have to buy a VIRL license to use your Ansible course materials? Or is VIRL in any Github repository? Is there a way to use your files in a free Tool like GNS3?
Let’s go through them one by one:
During Cisco Live Berlin 2017 Peter Jones (chair of several IEEE task forces) and myself went on a journey through 40 years of Ethernet history (and Token Bus and a few other choice technologies).
The sound quality is what you could expect from something recorded on a show floor with pigeons flying around, but I hope you’ll still enjoy our chat.
One of the sample Ansible playbooks I published to help the attendees of my Building Network Automation Solutions course get started collects LLDP neighbor information on all managed devices and converts that information into a network diagram.
Here’s the graph I got from it when I ran it on my 6-node OSPF network (the Inter-AS VIRL topology from this repository). Please note I spent zero time tweaking the graph description (it shows).
Some engineers solving the original challenges Johannes posted complained that they were too easy, so he created another scenario: find out what’s wrong in an IPsec setup using just the captured traffic. Good luck!
Got this comment on one of my blog posts:
When looking at some of the CLIs just front-ending RESTAPIs, I wonder if "survival" of CLI isn't just in the eyes of the beholder.
It made me really sad because I wrote about this exact topic several times… obviously in vain. Or as one of my network automation friends said when I asked him to look at the draft of this blog post:
Omer asked a pretty common question about BFD on one of my blog posts (slightly reworded):
Would you still use BFD even if you have a direct router-to-router physical link without L2 transport in the middle to detect if there is some kind of software failure on the other side?
Sander Steffann quickly replied:
Validating the expected network behavior is (according to the intent-driven pundits) a fundamental difference that makes intent-driven products more than glorified orchestration systems.
Guess what: smart people knew that for ages and validated their deployments even when using simple tools like Ansible playbooks.
Dinesh Dutt explained how he validates data center fabric deployment during the Network Automation Use Cases webinar; I’m doing something similar in my OSPF deployment playbooks (described in detail in Ansible online course).
One of my readers sent me an interesting DMVPN routing question. He has a design with a single DMVPN tunnel with two hubs (a primary and a backup hub), running BGP between hubs and spokes and IBGP session between hubs over a dedicated inter-hub link (he doesn’t want the hub-to-hub traffic to go over DMVPN).
Here's (approximately) what he's trying to do:
David Gee (whom I finally met in person during recent ipSpace.net Summit) published a fantastic series of articles on what someone bringing together networking, development and automation should know and do.
In every SDDC workshop I tried to persuade the audience that the virtual appliances (particularly per-application instances of virtual appliances) are the way to go. I usually got the questions along the lines of “who will manage and audit all these instances?” but once someone asked “and how will we upgrade them?”
Short answer: you won’t.
I listened to Ethan Banks’ presentation on lessons learned running active-active data centers years ago at Interop, and liked it so much that I asked him to talk about the same topic during the Building Next-Generation Data Center course.
Not surprisingly, Ethan did a stellar job, and when I heard he was working on QoS part of an upcoming book asked him whether he’d be willing to do a webinar on QoS.
Some of the things Ethan Banks writes are epic. The latest one I stumbled upon: Things Network Engineers Hate. I particularly loved the rant against long-distance vMotion (no surprise there ;).
One of the design scenarios we covered in Leaf-and-Spine Fabric Architectures webinar is a pure layer-3 data center, and in the “how do I do this” part of that section Dinesh Dutt talked about the details you need to know to get this idea implemented on Cumulus Linux.
In one of the previous blog posts I described the playbook I use to collect SSH keys from network devices. As I use it quite often, it became tedious to write ansible-playbook path-to-playbook every time I wanted to run the collection process.
Ansible playbooks are YAML documents, and YAML documents use # to start comments, so I thought “what if I’d use a YAML comment to add shebang and turn my YAML document into a script”
TL&DR: It works. Now for the longer story…
Second vendor in this year’s series of data center switching updates: Brocade.
Not much has happened on this front since last year’s update. There was a maintenance release of Brocade NOS, they launched SLX series of switches, but those are so new that the software documentation didn’t have time to make it to the usual place (document library for individual switch models), it's here.
In any case, the updated videos (including edited 2016 content which describes IP Fabric in great details) are online. You can access them if you bought the webinar recording in the past or if you have an active ipSpace.net subscription.
In case you’re not familiar with RFC 1925, Rule 5 states:
It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases, this is a bad idea.
Most routing protocols are a perfect demonstration of this rule.
Sometimes I have this weird feeling that I’m the only loony in town desperately preaching against the stupidities heaped upon infrastructure, so it’s really nice when I find a fellow lost soul. This is what another senior networking engineer sent me:
I'm belonging to a small group of people who are thinking that the source of the problem are the apps and the associated business/security rules: their nature, their complexity, their lifecycle...
Sounds familiar (I probably wrote a few blog posts on this topic in the past), and it only got better.
Gian Paolo Boarina published a great article following my Are You Solving the Right Problem rant.
Long story short: everyone in the networking game has their own agenda, and it’s not necessarily good for you or your business.
In June 2017, we concluded the Building Next Generation Data Center online course with a roundtable discussion with Andrew Lerner, Research Vice President, Networking, and Simon Richard, Research Director, Data Center Networking @ Gartner.
In the past 5+ years I ran at least one Data Center Fabrics Update webinar per year to cover new hardware and software launched by data center switching vendors.
The rate of product and feature launches in data center switching market is slowing down, so I decided to insert the information on new hardware and software features launched in 2017 directly into the merged videos describing the progress various vendors made in the last years.
One of my friends sent me this design challenge:
Assume you’re migrating from another WAN transport technology to MPLS. The existing network has 3000 routes but the MPLS carrier is limiting you to 1000 routes. How could you solve this with MPLS?
Personally, I think MPLS is a red herring.
A better question would be “how do you reduce the number of routes transported across your WAN network” or “how do you reduce the routing interaction with your MPLS service providers” (particularly intriguing if you use more than one of them).
As always, there are several options and it’s impossible to recommend the best one:
- Readdressing is usually out of question (or at least too messy to try). It might also break numerous firewall rules and other hard-coded stuff… unless you automated everything, but then it wouldn’t be hard to readdress, would it?
- The usual answer would be to summarize the routes. The usual challenge is that you might not be able to do it (because random addressing). Furthermore, summarization is a lossy compression, and loss of forwarding information might result in black holes.
- RFC 1925 states that there’s nothing that cannot be solved with another layer of abstraction. In this case, we could use any one or more of a half-dozen overlay technologies (IPsec, GRE, VXLAN, DMVPN, LISP…), or use an overlay technology sprinkled with unicorn dust (aka SD-WAN). The beauty of CE-to-CE tunnels is that they totally eliminate the need for PE-CE routing, and (when combined with VRFs) create independent routing domains, so you can use multiple SPs without the associated hassle.
- Finally, you could go for a really exotic solution like Carriers-Carrier (using additional MPLS labels as the data-plane abstraction mechanism).
You’d be totally wrong (and you’d deserve it – never trust a vendor peddling a product).
Here’s the list of webinars and events planned for October and November 2017:
- Second part of Network Visibility with Flow Data webinar on October 5th;
- Network automation workshop in Rome on October 18th;
- Cumulus Linux Update (part of Data Center Fabrics updates) on October 26th;
- QoS webinar on November 9th (no description yet);
- Day-long data center automation event in Zurich on November 14th (more details soon).
Hint: you get access to all live webinar sessions, and 170 hours of downloadable videos with ipSpace.net subscription.