Blog Posts in April 2018
Not long after I published the blog post arguing against physical appliances, Oven wrote a very valid comment: "But then you'd have 20 individual systems to manage, add licenses to for additional features, updates etc."
Even though the blog post (and the comment) was written in 2013, not much has changed in the meantime.
You probably know that fantastic feeling when you think your newly-discovered tool is a Hammer of Thor, capable of solving every problem (or at least crashing through it). I guess you’re also familiar with that sinking feeling when you’re trying to use your beloved hammer to whitewash a bikeshed.
Not surprisingly, the cruder the tool is, the quicker you’ll hit its limits, like when you try to do data processing in Jinja2 (hint: don’t).
I was listening to very interesting Future of Networking with Fred Baker a long while ago and enjoyed Fred’s perspectives and historical insight, until Greg Ferro couldn’t possibly resist the usual bashing of traditional routing protocols and praising of intent-based (or flow-based or SDN or…) whatever.
Here’s what I understood he said around 35:17
The network automation evangelists love to tell you that automation is more than just device configuration management. They’re absolutely right… but it’s nonetheless amazing how much good you could do with simple tools solving simple problems.
Here’s what I got from Nicky Davey:
Another month has swooshed by and it’s time for a refreshed list of upcoming webinars:
- Mitja Robas will explain the basics of NSX and ACI planning and design on April 24th. He has tons of material on this topic – expect to see him quite often in the autumn/winter timeframe;
- Dinesh Dutt will continue the EVPN Technical Deep Dive saga on May 3rd;
- Christoph Jaggi will run a free webinar on the basics of transport (layer-1/2) and network (layer-3) security on May 10th;
- We’ll run another SDDC webinar on May 22nd. More details later…
- On June 5th Christoph will be back with Ethernet Encryptors Deep Dive;
- The last webinar before the summer break will be Data Center Fabric Troubleshooting with Dinesh Dutt on June 19th.
All you need to have to attend all these live sessions is a current ipSpace.net webinar subscription.
One of my friends sent me this question:
Do you remember if VLANs came first or was it VRFs?
I remember VLANs using ISL (pre-802.1q encapsulation) on early Cisco Ethernet switches (mid 90s), the earliest reference I could track down on Wikipedia is from 1988.
Guess what I found: a software developer trying to persuade his peers that they need an API version of their CLI tool. Yes, I checked and it’s still 2018, and the year CLI dies seems to be a bit further out than some people thought.
I’d guess this proves that the rest of the world is not so far ahead of us lowly network engineers as blabbering pundits and vendor marketers would have us believe.
Needless to say, the engineers architecting Junos knew this almost 20 years ago.
As always, we started with the “what’s wrong with what we have right now, like using BGP as a better IGP” question, resulting in “BGP is becoming the trash can of the Internet”.
Here’s another back-to-the-fundamentals question I received a while ago when discussing IPv6 multihoming challenges:
I was wondering why enterprise can’t have dedicated block of IPv6 address and ISPs route the traffic to it. Enterprise shall select the ISP's based on the routing and preferences configured?
Let’s try to analyze where the problem might be. First the no-brainers:
I always love to read the practical advice by Andrew Lerner. Here’s another gem that matches what Brad Hedlund, Dinesh Dutt and myself (plus numerous others) have been saying for ages:
One specific recommendation we make in the research is to “Build a rightsized physical infrastructure by using a leaf/spine design with fixed-form factor switches and 25/100G capable interfaces (that are reverse-compatible with 10G).”
A while ago I did an interview about programmable infrastructure that got published as an article in mid-March. As you might expect, my main message was “technology will never save you unless you change your processes to adapt to its benefits.”
Hope you’ll enjoy it!
Got this question from a networking engineer who couldn’t decide whether to go for CCIE Data Center certification or attend my Building Next-Generation Data Center online course:
I am considering pursuing CCIE DC. I found your Next-Generation DC course very interesting. Now I am bit confused trying to decide whether to start with CCIE DC first and then do your course.
You might be in a similar position, so here’s what I told him.
Every second blue moon someone asks me whether they could buy ipSpace.net subscription with PayPal. So far, the answer has been no.
Recently we started testing whether we could use Digital River to solve a few interesting challenges we had in the past, and as they offer PayPal as a payment option, it seemed to be a perfect fit for a low-volume trial.
The only product that you can buy with PayPal during the trial is the standard subscription – just select PayPal as the payment method during the checkout process.
Finally: the first three subscribers using PayPal will get extra 6 months of subscription.
- The expert isn’t always right;
- An expert is far more likely to be right than you are;
- Experts come in many flavors – usually you need a combination of education and expertise;
- In any discussion, you have a positive obligation to learn at least enough to make the conversation possible. University of Google doesn’t count;
- While you’re entitled to have an opinion, having a strong opinion isn’t the same as knowing something.
Here's a trick question: how often do your Visio diagrams match what's really implemented in your network?
Wouldn't it be great to be able to create or modify them on-the-fly based on what's really configured in the network? That's exactly what Anthony Burke demonstrated in the PowerNSX part of PowerShell for Networking Engineers webinar (source code).
You’ll need at least free ipSpace.net subscription to watch the video.
The proponents of the “let’s run EVPN over EBGP underlay” idea often ignore an interesting challenge: EVPN advocates use of automatically-generated Route Targets, which might not work when every leaf switch uses a different AS number.
Remember the IPv6 elephant in the room – the inability to do small-site multihoming without NAT (well, NPT66)? IPv6 is old enough to buy its own beer, but the elephant is still hogging the room. Tons of ideas have been thrown around in IETF (mostly based on source address selection tricks), but none of that spaghetti stuck to the wall.
Stumbled upon this paragraph on Russ White’s blog:
I don’t really know how you write a certification that does not allow someone who has memorized the feature guide to do well. How do you test for protocol theory, and still have a broad enough set of test questions that they cannot be photographed and distributed?
As Russ succinctly explained the problem is two-fold:
One of my readers sent me a container security question after reading the Application Container Security Guide from NIST:
We are considering segregating dev/test/prod environments with bare-metal hardware. I did not find something in the standard concerning this. What should a financial institution do in your opinion?
I am no security expert and know just enough about containers to be dangerous, but there’s a rule that usually works well: use common sense and identify similar scenarios that have already been solved.
You cannot automate a process until you can describe it with enough details so that someone who has absolutely no clue what should be done can execute it.
David Gee published a long (and somewhat ranty) version of that statement. Enjoy!
In the second half of his Networks, Buffers and Drops webinar JR Rivers focused on end systems: what tools could you use to measure end-to-end TCP throughput, or monitor performance of an individual socket or the whole TCP stack?
You’ll need at least free ipSpace.net subscription to watch the video.
REST API is the way of the world and all network devices should support it, right? Well, Ken Duda (Arista) disagreed with this idea during his Networking Field Day presentation, but unfortunately there wasn’t enough time to go into the details that would totally derail the presentation anyway.
Fixing that omission: should we have REST API on network devices or not?
My BGP in EVPN-Based Data Center Fabrics blog post generated numerous comments from engineers disagreeing with my views on using IBGP-over-EBGP.
As usual, there were three kinds of comments:
The idea of generating random IPv6 addresses (so you cannot be tracked across multiple networks based on your MAC address) that stay stable within each subnet (so you don’t pollute everyone’s ND cache every time you open your iPad) is pretty old: RFC 7217 was published almost exactly four years ago.
Linux was quick to pick it up, OpenBSD got RFC 7127 support a few weeks ago. However, there’s an Easter egg in the OpenBSD patches that implement it: SLAAC on OpenBSD now works with any prefix length (not just /64).