New Open-Source IPAM + DCIM Tool

My friend Jeremy Stretch wrote an IPAM+DCIM tool for Digital Ocean and open-sourced it. As the tool was designed by networking engineers to manage data center networks (more in Jeremy’s blog post), it might be a better fit than other tools out there. In any case, check it out and let me know how it works.

Why Is Every SDN Vendor Bashing the Networking Engineers?

This blog post was written almost two years ago (and sat half-forgotten in a Word file somewhere in my Dropbox), but as it seems not much has changed in the meantime, it’s time to publish it anyway.

I was listening to the fantastic SDN Trinity podcast while biking around Slovenian hills and almost fell off the bike while furiously nodding to a statement along the lines of “I hate how every SDN vendor loves to bash networking engineers.”

Cutting through the IPv6 Requirements Red Tape

Few years ago a bunch of engineers agreed that the customers need a comprehensive “IPv6 Buyer’s Guide” and thus RIPE-554 was born. There are also IPv6 certification labs, US Government IPv6 profile and other initiatives. The common problem: all these things are complex.

However, it’s extremely easy to get what you want as Ron Broersma explained during his presentation at recent Slovenian IPv6 meeting. All it takes is a single paragraph in the RFP saying something along these lines:

The equipment must have the required functionality and performance in IPv6-only environment.

Problem solved (the proof is left as an exercise for the reader… or you could cheat and watch Ron’s presentation, which you should do anyway ;).

Typical SDN Architectures

Now that we know which definitions of SDN make no sense (and which one might) let’s see what a typical architecture of an SDN solution might look like.

I described some of them in the SDN 101 webinar, for more details watch the SDN Architectures and Deployment Guidelines webinar.

Does It Make Sense to Build Your Own Networking Solutions?

One of my readers was listening to the Snabb Switch podcast and started wondering “whether it’s possible to leverage and adopt these bleeding-edge technologies without a substantial staff of savvy programmers?”

Short answer: No. Someone has to do the heavy lifting, regardless of whether you have programmers on-site, outsource the work to contractors, or pay vendors to do it.

Awesome Response: Complexity Sells

Russ White wrote an awesome response to my Complexity Sells post:

[…] What we cannot do is forget that complexity is real, and we need to learn to manage it. What we must not do is continue to think we can play in the land of dragons forever, and not get burnt. […]

Now go and read the whole blog post ;)

Build Your Own Service Provider Gear on Software Gone Wild

A few days after I published a blog post arguing that most service providers cannot possibly copy Google’s ideas Giacomo Bernardi wrote a comment saying “well, we managed to build our own gear.”

Initially I thought they built their own Linux distribution on top of x86 server, but what Giacomo Bernardi described in Episode 59 of Software Gone Wild goes way beyond that:

Optimize Your Data Center: Reduce the Number of Uplinks

Remember our journey toward two-switch data center? So far we:

• Virtualized all workload we could;
• Removed legacy technologies.

Time for the next step: read a recent design guide from your favorite hypervisor vendor and reduce the number of server uplinks to two.

Not good enough? Building a bigger data center? There’s exactly one seat left in the Building Next Generation Data Center online course.

Directed ARP Saga Continues

Reading my Directed ARP and ICMP Redirects blog post you might have wondered “how did Directed ARP ever get into ***redacted***?”

I searched for “directed ARP cisco” and found this gem, which really talks about unicast ARP behavior, an ancient mechanism documented in RFC 1122 (it’s not my Google-Fu, I got the reference to RFC 1122 in this blog post).

On the Lossiness of TCP

When someone tells you that “TCP is a lossy protocol” during a job interview, don’t throw him out immediately – he was just trusting the Internet a bit too much (click to enlarge).

Everyone has a bad hair day, and it really doesn’t matter who published that text… but if you’re publishing technical information, at least try to do no harm.

Where Is the Explosion of Overlay Virtual Networks

Three years ago I was speaking with one of the attendees of my overlay virtual networking workshop @ Interop Las Vegas and he asked me how soon I thought the overlay virtual networking technologies would be accepted in the enterprise networks.

My response: “you might be surprised at the speed of the uptake.” Turns out, I was wrong (again). Today I’m surprised at the lack of that speed.

Big Chain Deep Dive on Software Gone Wild

A while ago Big Switch Networks engineers realized there’s a cool use case for their tap aggregation application (Big Tap Monitoring Fabric) – an intelligent patch panel traffic steering solution used as security tool chaining infrastructure in DMZ… and thus the Big Chain was born.

Curious how their solution works? Listen to Episode 58 of Software Gone Wild with Andy Shaw and Sandip Shah.

Complexity Sells

A blog post on Packet Pushers contained a quote by E. W. Dijkstra (of the SPF fame) and while trying to figure out whether that quote was real I stumbled upon his keynote address from a 1984 ACM conference (original). Not surprisingly, nothing has changed in the last 30+ years…

Directed ARP and ICMP Redirects

One of my readers sent me this question:

When I did my ***redacted*** I encountered a question about Directed ARP. The RFC (https://tools.ietf.org/html/rfc1433) is in the "experimental" stage, and I found it really weird from ***** to include such a hidden gem in the ***redacted***.

Directed ARP is clearly one of those weird things that people were trying out in the early days of networking when packet forwarding and bandwidth were still expensive (read the RFC for more details), but I kept wondering “what exactly is going on when a host receives an ICMP redirect?” Time for a hands-on test.

Is OVSDB a Control- or Management-Plane Protocol?

A while ago I discussed whether XMPP is a control- or management-plane protocol (spoiler: it depends). How about OVSDB? Here’s another question from one of my readers:

Why is Openflow considered as control plane protocol and OVSDB management plane protocol if both are relying on SDN controller? Is it because Openflow can directly modify the dataplane?

SDN controllers can use control- or management-plane protocols to get the job done.

Virtual Firewalls: Featured Webinar in June 2016

Virtual Firewalls is the featured webinar in June 2016, and the featured videos (marked with a star) explain the difference between virtual contexts and virtual appliances, and the virtual firewalls taxonomy.

To view the videos, log into my.ipspace.net (or enroll into the trial subscription if you don’t have an account yet), select the webinar from the first page, and watch the videos marked with star.

If you're a trial subscriber and would like to get access to the whole webinar, use this month's featured webinar discount (and keep in mind that every purchase brings you closer to the full subscription).

SDN as an Abstraction Layer

During the Introduction to SDN webinar I covered numerous potential definitions:

• It’s the separation of control and data plane;
• It’s software-based packet forwarding;
• It’s open networking and whitebox switching;
• It’s network programmability and device APIs.

I find all of these definitions too narrow or even misleading. However, the “SDN is a layer of abstraction” one is not too bad (see also RFC 1925 section 2.6a).

Is BGP Really that Complex?

Anyone following the popular networking blogs and podcasts is probably familiar with the claim that BGP is way too complex to be used in whatever environment. On the other hand, more and more smart people use it when building their data center or WAN infrastructure. There’s something wrong with this picture.

Every Product Needs to Scale… to a Point

Long time ago in a podcast far far away Greg and Ethan pondered whether networking solutions need to scale or not, and obviously one cannot disagree with their generic conclusion that enterprises need just-good-enough solutions and not Google-scale architectures.

However, do keep in mind that:

Using Macvlan and Ipvlan with Docker on Software Gone Wild

A few weeks after I published Docker Networking podcast, Brent Salisbury sent me an email saying “hey, we have experimental Macvlan and Ipvlan support for Docker” – a great topic for another podcast.

It took a while to get the stars aligned, but finally we got Brent, Madhu Venugopal, John Willis and Nick Buraglio on the same Skype call resulting in Episode 57 of Software Gone Wild.