Blog Posts in December 2019
Learning, Grades and Certifications
Cleaning my Inbox I found links to two interesting blog post: The Lesson to Unlearn and Coders in the Hand of a Missing God.
You might also want to read my old certification ramblings, or watch the How Networks Really Work webinar in case you care more about knowledge than certifications.
That's It for 2019 ;))
Yesterday we ran the last live webinar session for 2019, and all we have to do before locking the virtual office doors and returning to our families is to get the videos back from our editor and publish them. The “this is what we did in 2019” and “this is what we plan to do in 2020” blog posts will have to wait till we come back.
We’ll be (mostly) gone until early January… unless of course you have an urgent support problem. The desperate paperwork ideas like “I need you to sign, stamp, and notarize this legal document written in a language you’ve never seen in your life” will have to survive for a few weeks without our immediate attention (but then they usually don’t disappear on their own).
I hope you’ll be able to do something similar, disconnect from the crazy pace of networking world, forget all the unicorns you’ve been trying to tame during this year, and focus on your loved ones - they need you more than the router sitting in the basement of your building. We would also like to wish you all the best in 2020!
Oh, and I couldn’t resist adding this bit: if you’re looking for a gift for a fellow networking nerd, or have some leftover training budget that craves to be spent, we might have a few ideas…
Figure Out What Problem You’re Trying to Solve
A long while ago I got into an hilarious Tweetfest (note to self: don’t… not that I would ever listen) starting with:
Which feature and which Cisco router for layer2 extension over internet 100Mbps with 1500 Bytes MTU
The knee-jerk reaction was obvious: OMG, not again. The ugly ghost of BRouters (or is it RBridges or WAN Extenders?) has awoken. The best reply in this category was definitely:
I cannot fathom the conversation where this was a legitimate design option. May the odds forever be in your favor.
A dozen “this is a dumpster fire” tweets later the problem was rephrased as:
Video: FRRouting Overview
In October 2019, Donald Sharp did a short webinar describing FRRouting, the hottest open-source routing suite.
As always, he started with an overview of what FRRouting is, and where you could use it.
You Don't Need IP Renumbering for Disaster Recovery
This is a common objection I get when trying to persuade network architects they don’t need stretched VLANs (and IP subnets) to implement data center disaster recovery:
Changing IP addresses when activating DR is hard. You’d have to weigh the manageability of stretching L2 and protecting it, with the added complexity of breaking the two sites into separate domains [and subnets]. We all have apps with hardcoded IP’s, outdated IPAM’s, Firewall rules that need updating, etc.
Let’s get one thing straight: when you’re doing disaster recovery there are no live subnets, IP addresses or anything else along those lines. The disaster has struck, and your data center infrastructure is gone.
Practice Your Public Cloud Networking with Hands-On Exercises
Design assignments and hands-on exercises were always a big part of ipSpace.net online courses, and our new Networking in Public Cloud Deployments course is no different.
You’ll start with a simple scenario: deploy a virtual machine running a web server. Don’t worry about your Linux skills, you’ll get the necessary (CCIE-level) instructions and the source code for the web server. Building on that, you’ll create another subnet and deploy another virtual machine acting as a back-end application server.
And then we’ll get to the fun part:
EVPN Route Targets, Route Distinguishers, and VXLAN Network IDs
Got this interesting question from one of my readers:
BGP EVPN message carries both VNI and RT. In importing the route, is it enough either to have VNI ID or RT to import to the respective VRF?. When importing routes in a VRF, which is considered first, RT or the VNI ID?
A bit of terminology first (which you’d be very familiar with if you ever had to study how MPLS/VPN works):
BGP- and Car Safety
The Facts and Fiction: BGP Is a Hot Mess blog post generated tons of responses, including a thoughtful tweet from Laura Alonso:
Is your argument that the technology works as designed and any issues with it are a people problem?
A polite question like that deserves more than 280-character reply, but I tried to do my best:
BGP definitely works even better than designed. Is that good enough? Probably, and we could politely argue about that… but the root cause of most of the problems we see today (and people love to yammer about) is not the protocol or how it was designed but how sloppily it’s used.
Laura somewhat disagreed with my way of handling the issue:
Update: Using pyATS in Network Automation
A month ago I described how Paddy Kelly used pyATS to get VRF data from a Cisco router to create per-VRF connectivity graphs.
Recently he also wrote a short article describing how to get started with pyATS and Ansible. Thank you, Paddy!
Video: Cloud Models, Layers and Responsibilities
In late spring 2019, Matthias Luft and Florian Barth presented a short webinar on cloud concepts, starting with the obvious topic: cloud models, layers, and responsibilities.
Disaster Recovery and Failure Domains
One of the responses to my Disaster Recovery Faking blog post focused on failure domains:
What is the difference between supporting L2 stretched between two pods in your DC (which everyone does for seamless vMotion), and having a 30ms link between these two pods because they happen to be in different buildings?
I hope you agree that a single broadcast domain is a single failure domain. If not, let agree to disagree and move on - my life is too short to argue about obvious stuff.
Tuning BGP Convergence in High-Availability Firewall Cluster Design
Two weeks ago Nicola Modena explained how to design BGP routing to implement resilient high-availability network services architecture. The next step to tackle was obvious: how do you fine-tune convergence times, and how does BGP convergence compare to the more traditional FHRP-based design.
You Still Need a Networking Engineer for a Successful Cloud Deployment
You’ve probably heard cloudy evangelists telling CIOs how they won’t need the infrastructure engineers once they move their workloads into a public cloud. As always, whatever sounds too good to be true usually is. Compute resources in public clouds still need to be managed, someone still needs to measure application performance, and backups won’t happen by themselves.
Even more important (for networking engineers), network requirements don’t change just because you decided to use someone else’s computers:
Questions to Ask About Product Using Overhyped Technology
I stumbled upon a great MIT Technology Review article (warning: regwall ahead) with a checklist you SHOULD use whenever considering a machine-learning-based product.
While the article focuses on machine learning at least some of the steps in that list apply to any new product that claims to use a brand new technology in a particular problem domain like overlay virtual networking with blockchain: