Many vendors talk about network automation these days, and almost all of them gloss over an important detail: automation works best when you manage to simplify things to the bare minimum needed to get the job done.

One of the vendors that focus on simplifying the network device configuration is Cumulus Linux.

One of my readers sent me this question after listening to the podcast with Douglas Comer:

Professor Comer mentioned that IP choose a network attachment address model over an endpoint model because of scalability. He said if you did endpoint addressing it wouldn’t scale. I remember reading a bunch of your blog posts about CNLP (I hope I’m remembering the right acronym) and I believe you liked endpoint addressing better than network attachment point addressing.

As always, the answer is “it depends” (aka “we’re both right” ;).

During my recent SDN workshops I encountered several networking engineers who use Nexus 1000V in their data center environment, and some of them claimed their organization decided to do so to ensure the separation of responsibilities between networking and virtualization teams.

There are many good reasons one would use Nexus 1000V, but the one above is definitely not one of them.

One of my regular subscribers wondered whether it makes sense to attend a live workshop instead of listening to my webinars:

I am following your blog posts quite regularly, I’ve been a yearly subscriber for more than 3 years now and I’m even trying to attend as many webinars as I can in real time. Is there a real benefit to participate in this classroom event if we are almost aware of all your slide decks and videos?

Absolutely. Here’s what one of the attendees of a recent SDN workshop wrote when asking me whether I would be willing to do an on-site event for his company:

Whenever a vendor approaches me touting the benefits of their new gizmo, they want to give me a product demo, or offer me access to online labs… and I always tell them I’m not interested until I see their design and configuration guides.

Here’s why I think you should take the same approach:

Found an interesting article on High Scalability blog (another must-read web site) on how PostgreSQL improves locking behavior in high-volume transaction environment.

Needless to say, the feature is totally proprietaryrather unique and not available in most other database products. Improved locking behavior ⇒ improved lock-in.

Moral of the story: Stop yammering. Networking is no different from any other field of IT.

Update: Yep, I goofed up on the proprietary bit (it was one of those “I don’t think this word means what you think it means” gotchas). However, if you think open source product can't have proprietary features or you can’t get locked into an open-source product, I congratulate you on your rosy perspective. Reality smudged mine years ago.

You might remember the great idea David Barroso had last autumn – turn an Arista switch into an Internet edge router (SDN Internet Router – SIR). In the meantime, he implemented that solution in production environment serving high-speed links at multiple Internet exchange points. It was obviously time for another podcast on the same topic.

Every time I’m explaining the intricacies of new technologies to networking engineers, I try to use analogies with older well-known technologies, trying to make it simpler to grasp the architectural constraints of the shiny new stuff.

Unfortunately, most engineers younger than ~35 years have no idea what I’m talking about – all they know are Ethernet, IP and MPLS.

Just to give you an example – here’s a slide from my SDN workshop.

Another week, another ExpertExpress session, as is often the case focusing on two data centers with stretched VLANs spanning both of them. However, this one was particularly irksome, as the customer ran a firewall cluster stretched across two locations.

I gave the customer engineers my usual recommendations:

SD-WAN is all the rage these days (at least according to software-defined pundits), but networking engineers still build DMVPN networks, even though they are supposedly impossibly-hard-to-configure Rube Goldberg machinery.

To be honest, DMVPN is not the easiest technology Cisco ever developed, and there are plenty of gotchas, including the problem of default routing in Phase 2/3 DMVPN networks.