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.

While researching for another blog post, I stumbled upon this speech by Winston Churchill:

When the situation was manageable it was neglected, and now that it is thoroughly out of hand we apply too late the remedies which then might have effected a cure. There is nothing new in the story. It is as old as the Sibylline Books. It falls into that long, dismal catalogue of the fruitlessness of experience and the confirmed unteachability of mankind. Want of foresight, unwillingness to act when action would be simple and effective, lack of clear thinking, confusion of counsel until the emergency comes, until self-preservation strikes its jarring gong -these are the features which constitute the endless repetition of history.

Obviously mr. Churchill wasn't talking about IPv6 but about way more serious matters… but it's also obvious he was right abut the unteachability of mankind.

Jim Small asked me what I thought about the Future of Networking Packet Pushers podcast with Douglas Comer. I decided to listen to it while driving toward one of my recent hikes, and it was a great decision– it was the best Packet Pushers podcast I listened to in a long while.

Reiss Romoli, the fantastic organizers of my SDN/NFV event in Rome, Italy in late October are offering you a free personal ipSpace.net subscription – a saving of $299 or approximately EUR 270.

All you have to do to qualify is (A) download and fill in the registration form, (B) send it to Reiss Romoli and (C) pay before attending the webinar.

Yeah, I know the PDF form says “fax it back” – everyone has to use the tools that work best in their environment.

Hope we'll meet in warm and sunny Rome in a few weeks!

During one of my SDN workshops, an attendees asked me “How do you build carrier-grade (5 nines) cloud infrastructure with VMware NSX?”

Short answer: You don’t… and it’s a wrong question anyway.

A while ago I started discussing the intricate technical details of fibbing (an ingenious way of implementing traffic engineering with traditional OSPF) with Laurent Vanbever and other members of his group, and we decided to record a podcast on this topic.

Things never go as planned in a live chat, and we finished talking about another one of his projects – software defined Internet exchange point (SDX), the topic of Episode 41 of Software Gone Wild.

A year ago I was a firm believer in the unlimited powers of Software-Defined Data Centers and their ability to simplify workload migrations. After all, if you can use an API to create any data center object, what’s stopping you from moving the workload running in a data center to another location.

As always, there’s a huge difference between theory and reality.

I got into an interesting discussion with a fellow networking engineer trying to understand the impact of a switch failure in a L2/L3 data center fabric (anything from Avaya’s fabric or Brocade’s VCS Fabric to Cisco’s FabricPath, ACI or Juniper’s QFabric) on MAC and ARP tables.

Here’s my take on the problem – have I missed anything?

In a recent blog post Tom Hollingsworth made a great point: we should refocus from fighting one fire at a time to preventing fires.

I completely agree with him. However…

Dinesh Dutt started his part of the Data Center Fabrics Update webinar with “what is Cumulus Linux all about” and “what data center architectures does it support” and then quickly jumped into details about the base technologies used by Cumulus Linux: MLAG and IP routing.

Not surprisingly, the MLAG part generated tons of questions, and Dinesh answered all of them, even when he had to say “We don’t do that.”

If you’ve been a networking engineer (or a sysadmin) for a few years, you must be pretty familiar with DHCP and might think you know everything there is to know about this venerable protocol. So did I… until I read the article by Chris Marget in which he answers two interesting questions:

• How does the DHCP server (or relay) send DHCP offer to the client that doesn’t have an IP address (and doesn’t respond to ARP)?
• How does the DHCP client receive the DHCP responses if it doesn’t have an IP address?

When I wrote my stretched VSAN post, I thought VSAN uses asynchronous replication across WAN. Duncan Epping quickly pointed out that it uses synchronous replication, and I fixed the blog post.

The “What about latency?” question immediately arose somewhere in my subconscious, but before I could add that thought to the blog post, Anders Henke wrote a lengthy comment that totally captured what I was thinking, so I’m including it in its entirety: